From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Antonin Houska <antonin(dot)houska(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Oid registry |
Date: | 2012-09-26 14:21:33 |
Message-ID: | 23193.1348669293@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Antonin Houska <antonin(dot)houska(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2012-09-26 14:31:00 | Re: htup header reorganization breaks many extension modules |
Previous Message | Peter Eisentraut | 2012-09-26 14:18:51 | Re: htup header reorganization breaks many extension modules |