Antonin Houska <antonin.hou...@gmail.com> writes: > I'm also implementing an extension where direct access to non-fixed OIDs > (i.e. no catalog cache lookup by name) would be very helpful. I spent some > time thinking about a workaround that makes OID registry unnecessary. > How about the following?
> 1. Add a new varlena column to pg_proc catalog table, say > 'ext_types',containing > C array of OIDs. > 2. Let each extension declare requirements like the following in its > configuration > files: > "I expect <some type's name> type at 0-th position of 'ext_types' array." > "I expect <other type's name> type at 1-st position of 'ext_types' array." > etc. I think this just begs the question: how do you specify <some type> and how do you know that whatever was found is what you want? Beyond that, nothing in what you said can't be done today by a function that does type name lookups and caches the results internally. And I'd just as soon not burden the function-call infrastructure with more overhead to support something only a small fraction of functions would need. Another point is that server-internal features don't help client-side code, which is actually where most of the pain is AFAICT. We aren't providing any infrastructure that helps clients interpret PQftype() values for non-core types. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers