On Thu, Sep 10, 2009 at 4:38 PM, Hannu Krosing <hannu@2ndquadrant.com> wrote:
> On Thu, 2009-09-10 at 15:49 -0400, Tom Lane wrote:
>> Hannu Krosing <hannu@2ndQuadrant.com> writes:
>> > On Thu, 2009-09-10 at 15:06 -0400, Robert Haas wrote:
>> >> It might be possible to make it work, but it's likely to create a lot
>> >> of bloat in pg_type, and will make it very difficult to implement
>> >> features such as anonymous functions (i.e. LAMBDA).
>>
>> > For functions, anonymous does not mean "impossible to identify" ;)
>>
>> > If it is something (semi)-permanent we should store it in pg_type and id
>> > it by oid, if it is really, really transient (say a closure generated
>> > upper in the function chain) we can probably assign it some kind of
>> > temporary, per-process oid for the duration of its existence
>>
>> Right. See what we do for anonymous composite types.
>>
>>
>> > we could also change parser and translate reserved word ANY to typename
>> > "any" .
>>
>> ANY is a reserved word for good and sufficient reasons. "Change the
>> parser" is not an answer.
>
> I suspect that alt least in some early SQL parsers all type names were reserved.
>
> Or do you see a possible conflict here ?
>
> What way can ANY be used in function type definition ?
Perhaps you should try changing ANY to a non-reserved word in the
parser and see what happens. If you come up with a way to resolve the
shift/reduce and/or reduce/reduce conflicts that will probably result,
submit a patch.
...Robert
