Chapman Flack <chap@anastigmatix.net> writes:
> On 01/21/19 18:52, Tom Lane wrote:
>> I'm probably going to push forward with the OID mapping idea instead.
> As it happens, I'd been recently thinking[1] about a way that certain
> SQL/XML functionality could be provided by a pluggable selection of
> different extensions.
> And I think a use case like that could be rather elegantly served by
> the OID mapping idea, more so than by a fixed-OID-range-per-extension
> approach.
Hm, yeah. One use-case that's been in the back of my mind is
cross-extension references; for example, what if PostGIS wants
to map a call to one of its own functions into an indexable
operator that's defined by the btree_gist extension? What you're
talking about, IIUC, is a similar kind of reference only it goes
from the core code to an extension.
This line of thought says that the identifiers exposed by what
I was calling a SET MAP command would soon become part of the
de facto API of an extension: you'd not want to change them
for fear that some other extension was relying on them.
Perhaps this also gives some impetus to the lets-use-identifiers-
not-numbers approach that Andrew was pushing. I didn't care for
that too much so far as an extension's own internal references
are concerned, but for cross-extension references it seems a
lot better to be looking for "postgis / function_foo_int_int"
than for "postgis / 3".
On the third hand you could also say that such references should
just use name-based lookup and not a facility that's designed to
bypass the expense of that. Loading additional functionality
onto said facility just reduces its desired speed advantage.
(That is, in the terms of what I think you mean for the SQL/XML
business, an extension that's meant to serve that purpose would be
required to provide functions with specified names and signatures,
and the core would look them up that way rather than with any
behind-the-scenes API.)
regards, tom lane
