Re: proposal: new polymorphic types - commontype and commontypearray

Pavel Stehule <pavel.stehule@gmail.com>

From: Pavel Stehule <pavel.stehule@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Dmitry Dolgov <9erthalion6@gmail.com>, Greg Stark <stark@mit.edu>, David Steele <david@pgmasters.net>, Robert Haas <robertmhaas@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2020-03-15T18:23:36Z
Lists: pgsql-hackers
ne 15. 3. 2020 v 17:48 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:

> Pavel Stehule <pavel.stehule@gmail.com> writes:
> > Tom Lane <tgl@sss.pgh.pa.us> napsal:
> >> Yeah, that's what I said.  But does it really add anything beyond the
> >> proposed text "A function returning a polymorphic type must have at
> least
> >> one matching polymorphic argument"?  I don't think it'd be terribly
> >> helpful to say "A function returning anyelement must have at least one
> >> anyelement, anyarray, anynonarray, anyenum, or anyrange argument", and
> >> for sure such an error message would be a pain to maintain.
>
> > The error message in your first patch is ok for all types without
> anyrange.
> > A behave of this type is more strict and +/- different than from other
> > polymorphic types.
>
> Well, here's a version that does it like that, but personally I find these
> messages too verbose and not an improvement on what I had before.
>

There was a problem just with anyrange type. This last version looks
perfect.

Regards

Pavel


> (This is also rebased over the stuff I committed yesterday.)
>
>                         regards, tom lane
>
>

Commits

  1. Introduce "anycompatible" family of polymorphic types.

  2. Refactor our checks for valid function and aggregate signatures.

  3. Rearrange pseudotypes.c to get rid of duplicative code.