| From: | Joe Conway <mail(at)joeconway(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Hannu Krosing <hannu(at)tm(dot)ee>, "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org> |
| Subject: | Re: [HACKERS] SQL99 ARRAY support proposal |
| Date: | 2003-03-13 05:34:33 |
| Message-ID: | 3E701869.4020301@joeconway.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches |
Tom Lane wrote:
> Hmm. I don't see why we should drag ANY into this --- it should just be
> a no-constraints placeholder, same as before. What's the gain from
> constraining it that you don't get from ANYELEMENT?
[...snip...]
>> XXX should this case be rejected at the point of function creation?
>
> Probably. This case could be handled just as well by declaring the
> output to be ANY, I'd think.
[...snip...]
> Likewise. The point of (this reinterpretation of) ANYARRAY and
> ANYELEMENT is to let the parser deduce the actual output type.
> If it's not going to be able to deduce anything, use ANY instead.
Here's a new patch with the above corrections. I'm sending it to patches
in hopes it can be applied now rather than waiting. I think it stands
alone (shy some documentation, but I'm good for that ;-)) and makes
sense regardless of the other array support issues.
Thanks,
Joe
| Attachment | Content-Type | Size |
|---|---|---|
| array-gen.5.patch | text/plain | 15.9 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2003-03-13 05:37:58 | Re: [INTERFACES] Roadmap for FE/BE protocol redesign |
| Previous Message | Sailesh Krishnamurthy | 2003-03-13 04:43:21 | Re: some more docbook help |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2003-03-13 06:06:21 | Re: SQL99 ARRAY support proposal |
| Previous Message | Joe Conway | 2003-03-13 04:01:57 | Re: SQL99 ARRAY support proposal |