Lists: | pgsql-hackers |
---|
From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | determining a type oid from the name |
Date: | 2012-02-22 18:00:55 |
Message-ID: | 4F452D57.8060603@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Say I'm writing an extension X, and I want to process data values from
another extension that creates type Y (e.g. an hstore), what's the best
way to determine the Oid of type Y in my module X code? SPI code that
runs "select 'something'::Y" and then examines the oid in SPI_tuptable?
Or do we have a utility function I have missed that, given a type name
and the current search path will give me back the type Oid?
cheers
andrew
From: | Thom Brown <thom(at)linux(dot)com> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: determining a type oid from the name |
Date: | 2012-02-22 18:28:33 |
Message-ID: | CAA-aLv4hzyXNUmXfaSrtPyepPMhHec4_KRYG0N8m3=50OxymWw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
On 22 February 2012 18:00, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> Say I'm writing an extension X, and I want to process data values from
> another extension that creates type Y (e.g. an hstore), what's the best way
> to determine the Oid of type Y in my module X code? SPI code that runs
> "select 'something'::Y" and then examines the oid in SPI_tuptable? Or do we
> have a utility function I have missed that, given a type name and the
> current search path will give me back the type Oid?
Does this help?
test=# SELECT pg_typeof('4834.34'::numeric)::oid;
pg_typeof
-----------
1700
(1 row)
--
Thom
From: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
---|---|
To: | "Andrew Dunstan" <andrew(at)dunslane(dot)net>, "Thom Brown" <thom(at)linux(dot)com> |
Cc: | "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: determining a type oid from the name |
Date: | 2012-02-22 18:34:04 |
Message-ID: | 4F44E0BC0200002500045A28@gw.wicourts.gov |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Thom Brown <thom(at)linux(dot)com> wrote:
> Does this help?
>
> test=# SELECT pg_typeof('4834.34'::numeric)::oid;
> pg_typeof
> -----------
> 1700
> (1 row)
Wouldn't it be easier to do this instead?
test=# SELECT 'numeric'::regtype::oid;
oid
------
1700
(1 row)
-Kevin
From: | Thom Brown <thom(at)linux(dot)com> |
---|---|
To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: determining a type oid from the name |
Date: | 2012-02-22 18:36:35 |
Message-ID: | CAA-aLv6VAhzj3jWL3rR8_jS8q5DBQ5OQ-AhG-d7Ov6qVLZu9-Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
On 22 February 2012 18:34, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> Thom Brown <thom(at)linux(dot)com> wrote:
>> Does this help?
>>
>> test=# SELECT pg_typeof('4834.34'::numeric)::oid;
>> pg_typeof
>> -----------
>> 1700
>> (1 row)
>
> Wouldn't it be easier to do this instead?
>
> test=# SELECT 'numeric'::regtype::oid;
> oid
> ------
> 1700
> (1 row)
Well I may have misread the problem. I thought it was that for a
particular data value, the oid of the type of that value was needed.
--
Thom
From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Thom Brown <thom(at)linux(dot)com> |
Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: determining a type oid from the name |
Date: | 2012-02-22 19:14:10 |
Message-ID: | 4F453E82.1060005@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
On 02/22/2012 01:36 PM, Thom Brown wrote:
> On 22 February 2012 18:34, Kevin Grittner<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
>> Thom Brown<thom(at)linux(dot)com> wrote:
>>> Does this help?
>>>
>>> test=# SELECT pg_typeof('4834.34'::numeric)::oid;
>>> pg_typeof
>>> -----------
>>> 1700
>>> (1 row)
>> Wouldn't it be easier to do this instead?
>>
>> test=# SELECT 'numeric'::regtype::oid;
>> oid
>> ------
>> 1700
>> (1 row)
> Well I may have misread the problem. I thought it was that for a
> particular data value, the oid of the type of that value was needed.
Maybe I need to be more clear. The C code I'm writing will process
composites. I want to cache the Oids of certain non-builtin types in the
function info's fn_extra, and then be able to test whether or not the
fields in the composites are of those types.
cheers
andrew
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Thom Brown <thom(at)linux(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: determining a type oid from the name |
Date: | 2012-02-22 20:20:35 |
Message-ID: | 24151.1329942035@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Maybe I need to be more clear. The C code I'm writing will process
> composites. I want to cache the Oids of certain non-builtin types in the
> function info's fn_extra, and then be able to test whether or not the
> fields in the composites are of those types.
What's your basis for identifying those types in the first place?
Name? Doesn't seem terribly robust if the other extension can be
installed in some random schema. But anyway, something in
parser/parse_type.c ought to help you with that --- maybe
parseTypeString?
regards, tom lane
From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Thom Brown <thom(at)linux(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: determining a type oid from the name |
Date: | 2012-02-22 20:32:43 |
Message-ID: | 4F4550EB.2090106@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
On 02/22/2012 03:20 PM, Tom Lane wrote:
> Andrew Dunstan<andrew(at)dunslane(dot)net> writes:
>> Maybe I need to be more clear. The C code I'm writing will process
>> composites. I want to cache the Oids of certain non-builtin types in the
>> function info's fn_extra, and then be able to test whether or not the
>> fields in the composites are of those types.
> What's your basis for identifying those types in the first place?
> Name? Doesn't seem terribly robust if the other extension can be
> installed in some random schema. But anyway, something in
> parser/parse_type.c ought to help you with that --- maybe
> parseTypeString?
>
>
Thanks, that might do the trick.
I fully agree it's not bulletproof, but I'm not sure what alternative
there is.
cheers
andrew
From: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Thom Brown <thom(at)linux(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: determining a type oid from the name |
Date: | 2012-02-22 21:46:02 |
Message-ID: | m2obsqy21x.fsf@2ndQuadrant.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> I fully agree it's not bulletproof, but I'm not sure what alternative there
> is.
If you know the type has been installed as an extension you can look at
the extension's content in pg_depend, much like \dx+ does, limiting to
only types whose name matches.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support