On Fri, 2023-03-24 at 07:52 -0500, Merlin Moncure wrote:
> 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.
I'm not clear on what proposal you are making and/or endorising?
> 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.
Perhaps not special knowledge, but you need to know the structure. If
you have a query like "SELECT '...'::sometable", you still need to know
the structure of sometable to parse it.
> 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.
Wouldn't that only work if someone is doing a "SELECT *"?
Regards,
Jeff Davis
