Re: Domains versus polymorphic functions, redux
От | Merlin Moncure |
---|---|
Тема | Re: Domains versus polymorphic functions, redux |
Дата | |
Msg-id | BANLkTinfviJmjsPepaBFUacTB105oRMXNA@mail.gmail.com обсуждение исходный текст |
Ответ на | Domains versus polymorphic functions, redux (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Domains versus polymorphic functions, redux
|
Список | 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 по дате отправления: