Re: Oid registry

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Oid registry
Date: 2012-09-25 16:14:29
Message-ID: 21500.1348589669@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2012-09-25 16:16:06 Re: xlog filename formatting functions in recovery
Previous Message Amit Kapila 2012-09-25 15:27:06 Re: Re: [WIP] Performance Improvement by reducing WAL for Update Operation