Skip to content

value decoding (and encoding) needs additional access  #346

Open
@isoos

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

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