Skip to content

value decoding (and encoding) needs additional access  #346

Description

@isoos

My hesitance to go ahead with #342 and also with #343 has the same root: in their current form, they seem to be adding non-trivial complexity that could become barriers for the future improvements, while in the ideal world such features should be added with much less friction and much less interconnectedness.

After a some thinking and high-level fiddling, I think I have found a way forward though: we will need to refactor the value encoding/decoding to have access to:

  • connection settings (like client-provided timezone)
  • runtime parameter values (like server-provided timezone)
  • the TypeRegistry itself (there should be no need to use any other reference than the one provided in the connection settings)
  • the connection or ways to open a new connection + an OID cache that can use it to query yet-unknown identifiers (this becomes tricky in certain clusters so it shouldn't be 100% automatic caching)
  • user-provided transformation functions for specific types - e.g. to pull in larger timezone databases like pg_timezone, which may not be needed for all users

I'm not entirely sure how such code would look like, but I think the above feature would now only allow the two pending features to go ahead, but also allow better overall extensibility.

/cc @insinfo @wolframm

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions