On Sat, Mar 4, 2023 at 5:07 PM 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? > > 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. > > This seems slightly different since types depend upon schemas whereas search_path is top-level and tablespaces are global. But I agree that names should be accepted, maybe in addition to OIDs, the latter, for core types in particular, being a way to not have to worry about masking in user-space. David J.
