Re: [HACKERS] Missing array support

From: Joe Conway <mail(at)joeconway(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] Missing array support
Date: 2003-06-30 19:55:44
Message-ID: 3F0095C0.3010109@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Tom Lane wrote:
> Joe Conway <mail(at)joeconway(dot)com> writes:
>
> + * The rules for this resolution are as follows:
> + * 1) if the context type is polymorphic, punt and return type_to_resolve
> + * unchanged
> + * 2) if type_to_resolve is ANYARRAY (polymorphic), then return context_type
> + * if it is already an array type, or get its array type if not
> + * 3) if type_to_resolve is ANYELEMENT (polymorphic), then return context_type
> + * if it is already an elemental type, or get its element type if not
> + * 4) if type_to_resolve is non-polymorphic, return it unchanged
> + */
> + Oid
> + resolve_type(Oid type_to_resolve, Oid context_type)
>
> This seems wrong. ANYELEMENT doesn't imply conversion from array to
> element type. I don't think you're giving resolve_type nearly enough
> context to produce a correct answer.

And the function isn't trying to do that. If I have an ANYELEMENT I'm
trying to resolve, and the context type is a scalar type, it uses that.
If the context type is array, then it uses the array's element type.

> You're not providing enough info to resolve_type to let it handle all
> four cases correctly. In any case, this procedure seems exceedingly
> specific to the problem of resolving aggregate internal types. I doubt
> it should be in parse_type at all, and it certainly shouldn't have a
> name as generic as resolve_type.
>

No, resolve_type() is not at all specific to polymorphic aggregates. It
implements the rules of polymorphism that we previously agreed to,
namely that an ANYARRAY can be resolved by knowing any of these data
types at the time of function call:

1) the actual call type at the same position (i.e. argument number or
return type) as the ANYARRAY you're trying to resolve

2) the actual call type at a different position from the ANYARRAY you're
trying to resolve, as long as the declared type at that position is
either ANYARRAY or ANYELEMENT.

- If type_to_resolve is non-polymorphic, we have nothing in need of
resolution.

- If context_type is polymorphic, we have no context with which to do
resolution.

- If type_to_resolve is polymorphic (ANYARRAY or ANYELEMENT), and
context_type is not, resolve_type() picks the appropriate type based on
whether we need an array or not, and whether we've been given an array
or not as context.

Did you find a specific case where this falls down?

Joe

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-06-30 20:18:29 Re: [HACKERS] Missing array support
Previous Message Stephan Szabo 2003-06-30 19:37:39 Re: Is Patch Ok for deferred trigger disk queue?

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2003-06-30 20:18:29 Re: [HACKERS] Missing array support
Previous Message Tom Lane 2003-06-30 19:37:02 Re: [HACKERS] Missing array support