On Mon, 20 Mar 2023 at 19:10, Merlin Moncure <mmonc...@gmail.com> wrote:
> > > On Mon, Mar 13, 2023 at 3:33 PM Dave Cramer <davecra...@gmail.com> wrote: > >> >> Dave Cramer >> >> >> On Sat, 4 Mar 2023 at 19:39, Dave Cramer <davecra...@gmail.com> wrote: >> >>> >>> >>> On Sat, 4 Mar 2023 at 19:06, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> >>>> Jeff Davis <pg...@j-davis.com> writes: >>>> > On Sat, 2023-03-04 at 18:04 -0500, Dave Cramer wrote: >>>> >> Most of the clients know how to decode the builtin types. I'm not >>>> >> sure there is a use case for binary encode types that the clients >>>> >> don't have a priori knowledge of. >>>> >>>> > The client could, in theory, have a priori knowledge of a non-builtin >>>> > type. >>>> >>>> I don't see what's "in theory" about that. There seems plenty of >>>> use for binary I/O of, say, PostGIS types. Even for built-in types, >>>> do we really want to encourage people to hard-wire their OIDs into >>>> applications? >>>> >>> >>> How does a client read these? I'm pretty narrowly focussed. The JDBC API >>> doesn't really have a way to read a non built-in type. There is a facility >>> to read a UDT, but the user would have to provide that transcoder. I guess >>> I'm curious how other clients read binary UDT's ? >>> >>>> >>>> I don't see a big problem with driving this off a GUC, but I think >>>> it should be a list of type names not OIDs. We already have plenty >>>> of precedent for dealing with that sort of thing; see search_path >>>> for the canonical example. IIRC, there's similar caching logic >>>> for temp_tablespaces. >>>> >>> >>> I have no issue with allowing names, OID's were compact, but we could >>> easily support both >>> >> >> Attached is a preliminary patch that takes a list of OID's. I'd like to >> know if this is going in the right direction. >> >> Next step would be to deal with type names as opposed to OID's. >> This will be a bit more challenging as type names are schema specific. >> > > OIDs are a pain to deal with IMO. They will not survive a dump style > restore, and are hard to keep synchronized between databases...type names > don't have this problem. OIDs are an implementation artifact that ought > not need any extra dependency. > AFAIK, OID's for built-in types don't change. Clearly we need more thought on how to deal with UDT's > > > This seems like a protocol or even a driver issue rather than a GUC issue. > Why does the server need to care what format the client might want to > prefer on a query by query basis? > Actually this isn't a query by query basis. The point of this is that the client wants all the results for given OID's in binary. > I just don't see it. The resultformat switch in libpq works pretty well, > except that it's "all in" on getting data from the server, with the dead > simple workaround of casting to text which might even be able to be managed > from within the driver itself. > > merlin > > >
