On Tue, Mar 21, 2023 at 4:47 PM Jeff Davis <pgsql@j-davis.com> wrote:
On Tue, 2023-03-21 at 09:22 -0400, Dave Cramer wrote: > As Jeff mentioned there is a visibility problem if the search path is > changed. The simplest solution IMO is to look up the OID at the time > the format is requested and use the OID going forward to format the > output as binary. If the search path changes and a type with the same > name is now first in the search path then the data would be returned > in text.
Am I over-thinking this?
I think so. Dave's idea puts a lot of flexibility into the client side, and that's good. Search path mechanics are really well understood and well integrated with extensions already (create extension ..schema) assuming that the precise time UDT are looked up in an unqualified way is very clear to- or invoked via- the client code. I'll say it again though; OIDs really ought to be considered a transient cache of type information rather than a permanent identifier.
Regarding UDT, lots of common and useful scenarios (containers, enum, range, etc), do not require special knowledge to parse beyond the kind of type it is. Automatic type creation from tables is one of the most genius things about postgres and directly wiring client structures to them through binary is really nifty. This undermines the case that binary parsing requires special knowledge IMO, UDT might in fact be the main long term target...I could see scenarios where java classes might be glued directly to postgres tables by the driver...this would be a lot more efficient than using json which is how everyone does it today. Then again, maybe *I* might be overthinking this.
