Oid registry
This rather overdue mail arises out the developer's meeting back in May,
where we discussed an item I raised suggesting an Oid registry.
The idea came from some difficulties I encountered when I did the
backport of the JSON work we did in 9.2 to 9.1, but has wider
application. Say someone writes an extension that defines type A. You
want to write an extension that takes advantage of that type, but it's
difficult if you don't know the type's Oid, and of course currently
there is no way of knowing for sure what it is unless it's a builtin
type. So the proposal is to have an Oid registry, in which authors could
in effect reserve an Oid (or a couple of Oids) for a type. We would
guarantee that these Oids would be reserved in just the same way Oids
for builtins are reserved, and #define symbolic constants for the
reserved Oids. To make that viable, we'd need to extend the CREATE
commands for any objects we could reserve Oids for to allow for the
specification of the Oids, somewhat like:
CREATE TYPE newtype ( ....) WITH (TYPEOID = 123456, TYPEARRAYOID =
234567);
I'm not sure what objects we would need this for other than types, but
CREATE TYPE would be a good start anyway.
Another suggestion that was made during the discussion was that we
should also reserve a range of Oids for private use, and guarantee that
those would never be allocated, somewhat analogously to RFC1918 IP
addresses.
thoughts?
If there is general agreement I want to get working on this fairly soon.
cheers
andrew
Andrew Dunstan <andrew@dunslane.net> writes:
... So the proposal is to have an Oid registry, in which authors could
in effect reserve an Oid (or a couple of Oids) for a type. We would
guarantee that these Oids would be reserved in just the same way Oids
for builtins are reserved, and #define symbolic constants for the
reserved Oids. To make that viable, we'd need to extend the CREATE
commands for any objects we could reserve Oids for to allow for the
specification of the Oids, somewhat like:
CREATE TYPE newtype ( ....) WITH (TYPEOID = 123456, TYPEARRAYOID =
234567);
Well, of course, it's not clear how "reserved" an OID can be if you
provide SQL syntax that allows any Joe Blow to create a type with that
OID. The possibilities for security holes are interesting to say the
least, especially if applications blindly assume that oid 123456 *must*
be the type they think it is.
Another suggestion that was made during the discussion was that we
should also reserve a range of Oids for private use, and guarantee that
those would never be allocated, somewhat analogously to RFC1918 IP
addresses.
Likewise, "would never be allocated" and "we'll provide syntax that does
it trivially" seem a bit at odds.
Another point to think about is that it's a few years too late to
guarantee that any particular OID above 16384 is unused; we can't
do that now without possibly breaking pg_upgrade-ability of existing
databases. While we could hand out some subrange of the OIDs below
that, there's not exactly a huge amount of space available.
If there is general agreement I want to get working on this fairly soon.
Turning this into something actually useful seems to me to be a bit
harder than meets the eye. I'm not opposed to it in principle, but the
management aspect seems much more difficult than the technical aspect.
regards, tom lane
On Mon, 2012-09-24 at 18:59 -0400, Andrew Dunstan wrote:
This rather overdue mail arises out the developer's meeting back in
May, where we discussed an item I raised suggesting an Oid registry.The idea came from some difficulties I encountered when I did the
backport of the JSON work we did in 9.2 to 9.1, but has wider
application. Say someone writes an extension that defines type A. You
want to write an extension that takes advantage of that type, but it's
difficult if you don't know the type's Oid,
Could you fill the rest of us in with some technical details about why
this might be necessary and what it aims to achieve?
On 09/24/2012 09:37 PM, Peter Eisentraut wrote:
On Mon, 2012-09-24 at 18:59 -0400, Andrew Dunstan wrote:
This rather overdue mail arises out the developer's meeting back in
May, where we discussed an item I raised suggesting an Oid registry.The idea came from some difficulties I encountered when I did the
backport of the JSON work we did in 9.2 to 9.1, but has wider
application. Say someone writes an extension that defines type A. You
want to write an extension that takes advantage of that type, but it's
difficult if you don't know the type's Oid,Could you fill the rest of us in with some technical details about why
this might be necessary and what it aims to achieve?
Well, an obvious case is how record_to_json handles fields. If it knows
nothing about the type all it can do is output the string value. That
doesn't work well for types such as hstore. If it could reliably
recognize a field as an hstore it might well be able to do lots better.
cheers
andrew
On 09/24/2012 09:24 PM, Tom Lane wrote:
Andrew Dunstan <andrew@dunslane.net> writes:
... So the proposal is to have an Oid registry, in which authors could
in effect reserve an Oid (or a couple of Oids) for a type. We would
guarantee that these Oids would be reserved in just the same way Oids
for builtins are reserved, and #define symbolic constants for the
reserved Oids. To make that viable, we'd need to extend the CREATE
commands for any objects we could reserve Oids for to allow for the
specification of the Oids, somewhat like:
CREATE TYPE newtype ( ....) WITH (TYPEOID = 123456, TYPEARRAYOID =
234567);Well, of course, it's not clear how "reserved" an OID can be if you
provide SQL syntax that allows any Joe Blow to create a type with that
OID. The possibilities for security holes are interesting to say the
least, especially if applications blindly assume that oid 123456 *must*
be the type they think it is.
I think this would probably be a superuser-only facility.
Another suggestion that was made during the discussion was that we
should also reserve a range of Oids for private use, and guarantee that
those would never be allocated, somewhat analogously to RFC1918 IP
addresses.Likewise, "would never be allocated" and "we'll provide syntax that does
it trivially" seem a bit at odds.Another point to think about is that it's a few years too late to
guarantee that any particular OID above 16384 is unused; we can't
do that now without possibly breaking pg_upgrade-ability of existing
databases. While we could hand out some subrange of the OIDs below
that, there's not exactly a huge amount of space available.
we seem to have a fair bit of leeway between to top numbered Oid as
reported by unused_oids (4332) and 16384.
I would expect a private range of a few hundred to be more than
adequate, and a range for registered Oids of a couple of thousand to
last for many years. I'm expecting the use of this over quite a few
years to be numbered in tens, not thousands.
cheers
andrew
Andrew Dunstan <andrew@dunslane.net> writes:
On 09/24/2012 09:24 PM, Tom Lane wrote:
Another point to think about is that it's a few years too late to
guarantee that any particular OID above 16384 is unused; we can't
do that now without possibly breaking pg_upgrade-ability of existing
databases. While we could hand out some subrange of the OIDs below
that, there's not exactly a huge amount of space available.
we seem to have a fair bit of leeway between to top numbered Oid as
reported by unused_oids (4332) and 16384.
It's not nearly that simple. Per transam.h:
* OIDs 1-9999 are reserved for manual assignment (see the files
* in src/include/catalog/).
*
* OIDS 10000-16383 are reserved for assignment during initdb
* using the OID generator. (We start the generator at 10000.)
*
* OIDs beginning at 16384 are assigned from the OID generator
* during normal multiuser operation. (We force the generator up to
* 16384 as soon as we are in normal operation.)
pg_database.datlastsysoid is 12907 as of HEAD, so we're using about 2900
OIDs that are assigned during initdb. We should expect continued growth
in that number. For comparison, it was 10791 in 8.1, which was the first
version following this assignment scheme --- so the number of
auto-assigned OIDs has more than tripled in the last seven years.
And there's not room for another tripling. So I think it's entirely
likely that we'll have to reduce FirstBootstrapObjectId to a smaller
number in the foreseeable future, or else increase FirstNormalObjectId
which would be a pg_upgrade breaking move. Meanwhile, we do continue to
eat manually-assigned OIDs at a nontrivial pace as well.
So, yeah, we could reserve a couple hundred OIDs for a scheme like this
and (probably) not regret it later. But a couple thousand would scare
me ... and I'm not exactly convinced that a couple hundred is enough,
if there's any demand out there at all.
I suggest we could consider handing out reserved OIDs one or two at a
time using the current manual assignment process, *without* any notion
of a reserved block of OIDs. That is, when Joe Developer needs a couple
of OIDs for joes_whizzy_datatype, he comes to us and we say "sure, you
can have 4333 and 4334", which we then memorialize in a text file in
include/catalog/. This doesn't preclude doing something differently
later of course, but it avoids setting aside OID address space that is
likely to be underutilized and fairly desperately needed at some future
time.
As you might guess from this, I'm not enamored of the "reserve some
private OID space" part at all. There's not been any demand for that
that I've noticed. In pretty much any development context, you could
use OIDs up around 4 billion for such purposes and not have any problem
at all --- it's only trying to *guarantee* they're not used anywhere out
in the field that is problematic.
regards, tom lane
Andrew Dunstan <andrew@dunslane.net> writes:
On 09/24/2012 09:37 PM, Peter Eisentraut wrote:
Could you fill the rest of us in with some technical details about why
this might be necessary and what it aims to achieve?
Well, an obvious case is how record_to_json handles fields. If it knows
nothing about the type all it can do is output the string value. That
doesn't work well for types such as hstore. If it could reliably
recognize a field as an hstore it might well be able to do lots better.
Um ... that is an entirely unconvincing use case. We would not put any
code into core that knows specifically about a non-core datatype, or
at least I sure hope we'd not do such a klugy thing. It would be far
better to invent an extensibility scheme (plug-in of some sort) for
record_to_json.
My recollection of the PGCon discussion is that people wanted to allow
client-side code to hard-wire type OIDs for add-on types, in more or
less the same way that things like JDBC know that "25" is "text".
That's not unreasonable, since the alternatives are complicated and
not all that reliable. I'm not sure the usage applies to anything
except data types though, so at least for starters I'd only want to
accept reservations of OIDs for data types.
regards, tom lane
On Mon, Sep 24, 2012 at 8:21 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
So, yeah, we could reserve a couple hundred OIDs for a scheme like this
and (probably) not regret it later. But a couple thousand would scare
me ... and I'm not exactly convinced that a couple hundred is enough,
if there's any demand out there at all.
I think some kind of way to compose extension objects -- this includes
and goes beyond just the things in pg_type, but operators and so on --
will have great impact on Postgres' power without making the community
effort unscalable. I think PostGIS is the largest success by this
metric -- although certain requirements spill back into pgsql-hackers,
it's a pretty huge island of functionality out there that neatly
progresses on its own without coordination. That's fantastic.
I am fairly certain that if some form of in-line extensions were
supported, we would see people building smaller extensions that use
many little types (such as composites) relying on other extensions to
do things or manage certain tables, increasing convenience overall.
Things like the JSON data type (in spite of my own opinion that it
should be added) are a highly useful concession. Yet, it is still a
concession that extensions simply cannot be as close to good as a core
data type when it comes to the ability to compose. The gap between
pre-JSON-in-the-standard-library in Python, Ruby, et al and
post-JSON-in-stdlib was much smaller. Even for statically typed
languages -- like Java -- the only central-registries that exist are
mostly for the convenience of distribution and deployment, not as the
means of composition, and I think that is a good thing.
However, an IANA-style OID registry I find pretty un-compelling. Is
there no way we can use symbols, the type system, and invalidation
messages to a client to do this? I feel like there is a way we can,
and it is probably worth it to minimize coordination among extension
authors and enabling smaller extensions.
If reserved OID ranges for extensions are to become a thing, I think
the right scope would be to presume that these extensions are not
bundled with Postgres, but practically, whoever uses that space is
probably going to have to be the kind of person who would correspond
with -hackers. Ad-hoc composition among small or live-and-die-fast
user-space libraries (that are written in trusted languages, for
example) are out, which is kind of a bummer for what I think plv8 can
enable.
--
fdr
On Mon, Sep 24, 2012 at 8:39 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Andrew Dunstan <andrew@dunslane.net> writes:
On 09/24/2012 09:37 PM, Peter Eisentraut wrote:
Could you fill the rest of us in with some technical details about why
this might be necessary and what it aims to achieve?Well, an obvious case is how record_to_json handles fields. If it knows
nothing about the type all it can do is output the string value. That
doesn't work well for types such as hstore. If it could reliably
recognize a field as an hstore it might well be able to do lots better.Um ... that is an entirely unconvincing use case. We would not put any
code into core that knows specifically about a non-core datatype, or
at least I sure hope we'd not do such a klugy thing. It would be far
better to invent an extensibility scheme (plug-in of some sort) for
record_to_json.
I don't think (and not hope) the core should know about external data
type, but I have certainly seen a lot of use cases where an external
project wants to know about another external data type. Say, if plv8
wants to convert hstore into a javascript object. It is arbitrary for
users to define such a function that accepts hstore as arguments, but
how does plv8 know the input is actually hstore? Of course you can
look up type name conlusting SysCache and see if the type name is
"hstore", but it's expensive to do it for every function invocation,
so caching the hstore's oid in plv8 is the current workaround, which
is not truly safe because the hstore's oid may change while caching.
I can tell similar stories around array creation which needs element
type oid. The core code can do some special stuff by using
pre-defined type or function oid macros, and I guess it is reasonable
for the external developers to hope to do such things.
Thanks,
--
Hitoshi Harada
On 24 September 2012 21:26, Andrew Dunstan <andrew@dunslane.net> wrote:
On 09/24/2012 09:37 PM, Peter Eisentraut wrote:
On Mon, 2012-09-24 at 18:59 -0400, Andrew Dunstan wrote:
This rather overdue mail arises out the developer's meeting back in
May, where we discussed an item I raised suggesting an Oid registry.The idea came from some difficulties I encountered when I did the
backport of the JSON work we did in 9.2 to 9.1, but has wider
application. Say someone writes an extension that defines type A. You
want to write an extension that takes advantage of that type, but it's
difficult if you don't know the type's Oid,Could you fill the rest of us in with some technical details about why
this might be necessary and what it aims to achieve?Well, an obvious case is how record_to_json handles fields. If it knows
nothing about the type all it can do is output the string value. That
doesn't work well for types such as hstore. If it could reliably recognize a
field as an hstore it might well be able to do lots better.
I think we're missing something in the discussion here.
Why can't you find out the oid of the type by looking it up by name?
That mechanism is used throughout postgres already and seems to work
just fine.
Why would we need to hardcode it?
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On 09/25/2012 04:26 AM, Andrew Dunstan wrote:
On 09/24/2012 09:37 PM, Peter Eisentraut wrote:
On Mon, 2012-09-24 at 18:59 -0400, Andrew Dunstan wrote:
This rather overdue mail arises out the developer's meeting back in
May, where we discussed an item I raised suggesting an Oid registry.The idea came from some difficulties I encountered when I did the
backport of the JSON work we did in 9.2 to 9.1, but has wider
application. Say someone writes an extension that defines type A. You
want to write an extension that takes advantage of that type, but it's
difficult if you don't know the type's Oid,Could you fill the rest of us in with some technical details about why
this might be necessary and what it aims to achieve?Well, an obvious case is how record_to_json handles fields. If it
knows nothing
about the type all it can do is output the string value. That doesn't
work well
for types such as hstore. If it could reliably recognize a field as an
hstore it
might well be able to do lots better.
During the earlier to_json() discussions I already proposed a solution
to this - try
a cast to JSON type before falling back to outputting the text version.
As I understand it, this is how typecasts are supposed to be used.
In addition to being "how PostgreSQL is intended to work" it also allows
for users
to override it and have their own version of json representations for
types which have no
standard json format.
Just for the record - I'm not opposed to having a PostgreSQL OID
Registry though I think
that for anything in the backend the lookup by name should be fast enough.
Show quoted text
cheers
andrew
On Tue, Sep 25, 2012 at 1:06 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
On 24 September 2012 21:26, Andrew Dunstan <andrew@dunslane.net> wrote:
Well, an obvious case is how record_to_json handles fields. If it knows
nothing about the type all it can do is output the string value. That
doesn't work well for types such as hstore. If it could reliably recognize a
field as an hstore it might well be able to do lots better.I think we're missing something in the discussion here.
Why can't you find out the oid of the type by looking it up by name?
That mechanism is used throughout postgres already and seems to work
just fine.
Sure, but how do you know the type named "hstore" is what you know as
hstore? We don't have a global consensus a specific type name means
exactly what everyone thinks it is.
Thanks,
--
Hitoshi Harada
On 25.09.2012 12:19, Hitoshi Harada wrote:
On Tue, Sep 25, 2012 at 1:06 AM, Simon Riggs<simon@2ndquadrant.com> wrote:
On 24 September 2012 21:26, Andrew Dunstan<andrew@dunslane.net> wrote:
Well, an obvious case is how record_to_json handles fields. If it knows
nothing about the type all it can do is output the string value. That
doesn't work well for types such as hstore. If it could reliably recognize a
field as an hstore it might well be able to do lots better.
I'm not at all familiar with record_to_json or the json datatype, but
wouldn't it be appropriate to create a cast from hstore to json to
handle that case?
That brings us to another question: should the cast be part of the
hstore extension, or json? (json is built-in, but imagine for a moment
that it was an extension, too, so that there was a choice). IIRC someone
started a discussion on that recently on pgsql-hackers, but I don't
think there was any conclusion on that.
I think we're missing something in the discussion here.
Why can't you find out the oid of the type by looking it up by name?
That mechanism is used throughout postgres already and seems to work
just fine.Sure, but how do you know the type named "hstore" is what you know as
hstore? We don't have a global consensus a specific type name means
exactly what everyone thinks it is.
If you create a type called "hstore" that isn't the one in
contrib/hstore, you're just asking for trouble. Having a central
registry of assigned oid numbers doesn't really make that problem go
away either; you could still assign one of the registered oids for a
different datatype if you wanted to.
So whether you rely on the oid or type name, your code needs to behave
sanely, even if the datatype doesn't behave the way you'd expect. At a
minimum, there needs to be sanity checks so that you don't crash, and
give a meaningful error message. Beyond that, I think it's the user
responsibility to not confuse things by using well-known datatype names
like "hstore" for something else.
Here's another thought: imagine that someone creates a datatype that's
more or less compatible with contrib/hstore, but the internal
implementation is different. Would you call that hstore? Would you use
the same assigned oid for it? If you have some other extension that
knows about hstore, and treats it specially, would you want the new
datatype to be treated specially too?
And what about domains? If you have code that knows the oid of hstore
and gives it special treatment, should domains over hstore also be given
special treatment?
- Heikki
On 09/25/2012 06:13 AM, Heikki Linnakangas wrote:
On 25.09.2012 12:19, Hitoshi Harada wrote:
On Tue, Sep 25, 2012 at 1:06 AM, Simon Riggs<simon@2ndquadrant.com>
wrote:On 24 September 2012 21:26, Andrew Dunstan<andrew@dunslane.net> wrote:
Well, an obvious case is how record_to_json handles fields. If it
knows
nothing about the type all it can do is output the string value. That
doesn't work well for types such as hstore. If it could reliably
recognize a
field as an hstore it might well be able to do lots better.I'm not at all familiar with record_to_json or the json datatype, but
wouldn't it be appropriate to create a cast from hstore to json to
handle that case?
No, the difficulty (or at least the first difficulty) is in having the
code recognize that it has an hstore at all. The code picks apart the
record field by field at run time and takes various actions depending on
the field's type. For any type it doesn't recognize it just outputs the
value as a string, and so that's what it does with hstore. Mostly this
is the right thing but in the hstore case it's rather sad.
That brings us to another question: should the cast be part of the
hstore extension, or json? (json is built-in, but imagine for a moment
that it was an extension, too, so that there was a choice). IIRC
someone started a discussion on that recently on pgsql-hackers, but I
don't think there was any conclusion on that.I think we're missing something in the discussion here.
Why can't you find out the oid of the type by looking it up by name?
That mechanism is used throughout postgres already and seems to work
just fine.Sure, but how do you know the type named "hstore" is what you know as
hstore? We don't have a global consensus a specific type name means
exactly what everyone thinks it is.If you create a type called "hstore" that isn't the one in
contrib/hstore, you're just asking for trouble. Having a central
registry of assigned oid numbers doesn't really make that problem go
away either; you could still assign one of the registered oids for a
different datatype if you wanted to.
That's true to some extent, but names are worse, since they are schema
qualified.
cheers
andrew
On 09/24/2012 11:39 PM, Tom Lane wrote:
My recollection of the PGCon discussion is that people wanted to allow
client-side code to hard-wire type OIDs for add-on types, in more or
less the same way that things like JDBC know that "25" is "text".
That's not unreasonable, since the alternatives are complicated and
not all that reliable. I'm not sure the usage applies to anything
except data types though, so at least for starters I'd only want to
accept reservations of OIDs for data types.
Yes, I certainly think that's a sufficient case. And just to be clear, I
don't care about the "private range" suggestion. I was just reporting
that as it came up in the discussion and at least wasn't immediately
shouted down. But I'm happy to abandon it at least for now. If there is
ever actual demand for it we could revisit the matter.
Given your previous comments, perhaps we could just start handing out
Oids (if there is any demand) numbered, say, 9000 and up. That should
keep us well clear of any existing use.
Regarding the use of pre-allocated Oids, unless we provide some facility
to use them when creating types extension authors will be reduced to
using the pretty ugly tricks I had to use when backporting JSON for
binary upgrade-ability. This used some of pg_upgrade's tricks to force
use of particular Oids, but I don't think this should be recommended
practice. The suggestion I made was based on something you suggested
(albeit with some caveats) in the recent discussion of pg_upgrade with
extensions.
cheers
andrew
Andrew Dunstan <andrew@dunslane.net> writes:
Given your previous comments, perhaps we could just start handing out
Oids (if there is any demand) numbered, say, 9000 and up. That should
keep us well clear of any existing use.
No, I think you missed my point entirely: handing out OIDs at the top
of the manual assignment range is approximately the worst possible
scenario. I foresee having to someday move FirstBootstrapObjectId
down to 9000, or 8000, or even less, to cope with growth of the
auto-assigned OID set. So we need to keep manually assigned OIDs
reasonably compact near the bottom of the range, and it doesn't matter
at all whether such OIDs are used internally or reserved for external
developers. Nor do I see a need for such reserved OIDs to "look
different" from internally-used OIDs. Reserved is reserved.
regards, tom lane
On 09/25/2012 10:23 AM, Tom Lane wrote:
Andrew Dunstan <andrew@dunslane.net> writes:
Given your previous comments, perhaps we could just start handing out
Oids (if there is any demand) numbered, say, 9000 and up. That should
keep us well clear of any existing use.No, I think you missed my point entirely: handing out OIDs at the top
of the manual assignment range is approximately the worst possible
scenario. I foresee having to someday move FirstBootstrapObjectId
down to 9000, or 8000, or even less, to cope with growth of the
auto-assigned OID set. So we need to keep manually assigned OIDs
reasonably compact near the bottom of the range, and it doesn't matter
at all whether such OIDs are used internally or reserved for external
developers. Nor do I see a need for such reserved OIDs to "look
different" from internally-used OIDs. Reserved is reserved.
OK, point taken.
cheers
andrew
Excerpts from Hitoshi Harada's message of mar sep 25 02:11:14 -0300 2012:
Of course you can
look up type name conlusting SysCache and see if the type name is
"hstore", but it's expensive to do it for every function invocation,
so caching the hstore's oid in plv8 is the current workaround, which
is not truly safe because the hstore's oid may change while caching.
Hm, couldn't you just register an invalidation callback with
CacheRegisterSyscacheCallback()?
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
Excerpts from Hitoshi Harada's message of mar sep 25 02:11:14 -0300 2012:
Of course you can
look up type name conlusting SysCache and see if the type name is
"hstore", but it's expensive to do it for every function invocation,
so caching the hstore's oid in plv8 is the current workaround, which
is not truly safe because the hstore's oid may change while caching.
Hm, couldn't you just register an invalidation callback with
CacheRegisterSyscacheCallback()?
Yeah, if the code that needs the value is in the backend; but if it is,
the cost of looking the value up again probably isn't that much either.
The need for a cache is much greater in client-side code.
The bigger issues in my mind have to do with how you look up the type in
the first place (considering schema search path and so forth) and how
you know that "hstore" is what you think it is.
I recall some discussion of assigning a UUID to each datatype, which
might alleviate the second part of that at least. Does nothing for
malicious impersonation of a datatype of course, but should prevent
accidental collisions.
regards, tom lane
On 09/25/2012 12:14 PM, Tom Lane wrote:
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
Excerpts from Hitoshi Harada's message of mar sep 25 02:11:14 -0300 2012:
Of course you can
look up type name conlusting SysCache and see if the type name is
"hstore", but it's expensive to do it for every function invocation,
so caching the hstore's oid in plv8 is the current workaround, which
is not truly safe because the hstore's oid may change while caching.Hm, couldn't you just register an invalidation callback with
CacheRegisterSyscacheCallback()?Yeah, if the code that needs the value is in the backend; but if it is,
the cost of looking the value up again probably isn't that much either.
The need for a cache is much greater in client-side code.The bigger issues in my mind have to do with how you look up the type in
the first place (considering schema search path and so forth) and how
you know that "hstore" is what you think it is.I recall some discussion of assigning a UUID to each datatype, which
might alleviate the second part of that at least. Does nothing for
malicious impersonation of a datatype of course, but should prevent
accidental collisions.
One nice thing about that idea (if I understand it correctly) is that we
could use it for existing types. The horse has long bolted on Oids for
hstore, because it has lots of existing deployments with unknown Oids.
cheers
andrew
