| From: | "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> |
|---|---|
| To: | "Joe Conway" <mail(at)joeconway(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Hannu Krosing" <hannu(at)tm(dot)ee>, "Hackers (PostgreSQL)" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: SQL99 ARRAY support proposal |
| Date: | 2003-03-11 01:25:34 |
| Message-ID: | 00b501c2e76d$207204f0$6500a8c0@fhp.internal |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches |
> So if I understand correctly, all instances of anyarray and anyelement
> in a function definition would need to be self-consistent, but the group
> could represent essentially any datatype with its corresponding array
> type. If we need more than one of these self consistent groups, we could
> resort to anyarray1/anyelement1, etc. Does this sound correct?
>
> Also, an implementation question: if I have a type oid for an element,
> what is the preferred method for determining the corresponding array?
> I'm thinking that the most efficient method might be to use the
> element-type name with a '_' prepended to get the array-type oid, but
> that seems ugly. Thoughts?
What about a cast? 1::arraytype
Chris
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2003-03-11 02:27:06 | Re: Roadmap for FE/BE protocol redesign |
| Previous Message | Tom Lane | 2003-03-11 00:48:41 | Re: Roadmap for FE/BE protocol redesign |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christopher Kings-Lynne | 2003-03-11 05:28:04 | pg_get_triggerdef |
| Previous Message | Tom Lane | 2003-03-10 22:26:06 | Re: spelling corrections |