From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org, lr(at)pcorp(dot)us |
Subject: | Re: Domains versus polymorphic functions, redux |
Date: | 2011-05-24 16:44:01 |
Message-ID: | BANLkTinfviJmjsPepaBFUacTB105oRMXNA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, May 24, 2011 at 11:12 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | David E. Wheeler | 2011-05-24 16:46:08 | Re: Domains versus polymorphic functions, redux |
Previous Message | Noah Misch | 2011-05-24 16:34:26 | Re: Reducing overhead of frequent table locks |