| 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 |
| Thread: | |
| 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 | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2012-02-22 20:22:29 | Re: pg_upgrade --logfile option documentation |
| Previous Message | Bruce Momjian | 2012-02-22 20:01:10 | Re: pg_upgrade --logfile option documentation |