From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Joe Conway <mail(at)joeconway(dot)com> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: array support patch phase 1 patch |
Date: | 2003-04-08 16:37:07 |
Message-ID: | 3435.1049819827@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Joe Conway <mail(at)joeconway(dot)com> writes:
>>> 5. Side note: I added ANYARRAY1 and ANYELEMENT1 in this version.
>>
>> Doing what?
> The problem lies in that fact that more than one reference to ANYARRAY
> in the argument list of a function implies that the said arrays are all
> the same data type. This doesn't work for a coercion function where you
> need two array arguments, of arbitrary types, but that are not the same
> as each other. I could not see any other clean way to achieve this.
What I'm currently thinking of is declaring array_coerce to take and
return ANYARRAY (which will make it a no-op if someone tries to invoke
it by hand). The coercion code will have to force the output type to
the desired thing after building the FuncExpr node. But the other way
needs special-case code in parse_coerce too, and it doesn't do something
reasonable if array_coerce is invoked by hand.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2003-04-08 16:55:51 | Re: array support patch phase 1 patch |
Previous Message | Joe Conway | 2003-04-08 16:19:13 | Re: array support patch phase 1 patch |