If there's some extension that offers type "mytype", and perhaps allows it to be installed in any schema, then it seems that the client library would know how to parse all instances of "mytype" regardless of the schema or search_path.
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.
The binary format parameter would ordinarily be set by the maintainer of the client library, who knows nothing about the schema the client might be accessing, and nothing about the search_path that might be set. They would only know which binary parsers they've already written and included with their client library.
With that in mind, using search_path at all seems weird. Why would a change in search_path affect which types the client library knows how to parse? If the client library knows how to parse "foo.mytype"'s binary representation, and you change the search path such that it finds "bar.mytype" instead, did the client library all of a sudden forget how to parse "foo.mytype" and learn to parse "bar.mytype"?
If there's some extension that offers type "mytype", and perhaps allows it to be installed in any schema, then it seems that the client library would know how to parse all instances of "mytype" regardless of the schema or search_path.
Of course, a potential problem is that ordinary users can create types (e.g. enum types) and so you'd have to be careful about some tricks where someone shadows a well-known extension in order to confuse the client with unexpected binary data (not sure if that's a security concern or not, just thinking out loud).
One solution might be that unqualified type names would work on all types of that name (in any schema) that are owned by a superuser, regardless of search_path. Most extension scripts will be run as superuser anyway. It would feel a little magical, which I don't like, but would work in any practical case I can think of.
Another solution would be to have some extra catalog field in pg_type that would be a "binary format identifier" and use that rather than the type name to match up binary parsers with the proper type.
