Re: Domains versus polymorphic functions, redux - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: Domains versus polymorphic functions, redux
Date
Msg-id BANLkTinfviJmjsPepaBFUacTB105oRMXNA@mail.gmail.com
Whole thread Raw
In response to Domains versus polymorphic functions, redux  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Domains versus polymorphic functions, redux  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, May 24, 2011 at 11:12 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 1. If a domain type is passed to an ANYARRAY argument, automatically
> downcast it to its base type (which of course had better then be an
> array).  This would include inserting an implicit cast into the
> expression tree, so that if the function uses get_fn_expr_argtype or
> similar, it would see the base type.  Also, if the function returns
> ANYARRAY, its result is considered to be of the base type not the
> domain.

Does that mean that plpgsql %type variable declarations will see the
base type (and miss any constraint checks?).  I think it's fine either
way, but that's worth noting.

> An alternative rule we could use in place of #2 is just "smash domains
> to base types always, when they're matched to ANYELEMENT".  That would
> be simpler and more in keeping with #1, but it might change the behavior
> in cases where the historical behavior is reasonable (unlike the cases
> discussed in my message referenced above...)  I find this simpler rule
> tempting from an implementor's standpoint, but am unsure if there'll be
> complaints.

#2a seems cleaner to me (superficially).  Got an example of a behavior
you think is changed?  In particular, is there a way the new function
would fail where it used to not fail?

merlin


pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: Reducing overhead of frequent table locks
Next
From: "David E. Wheeler"
Date:
Subject: Re: Domains versus polymorphic functions, redux