Re: hstore dump/restore bug in 9.3
От | Tom Lane |
---|---|
Тема | Re: hstore dump/restore bug in 9.3 |
Дата | |
Msg-id | 26582.1399866533@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: hstore dump/restore bug in 9.3 (Craig Ringer <craig@2ndquadrant.com>) |
Ответы |
Re: hstore dump/restore bug in 9.3
|
Список | pgsql-bugs |
Craig Ringer <craig@2ndquadrant.com> writes: > On 05/12/2014 10:18 AM, Craig Ringer wrote: >> Do we need a way to schema-qualify the operator used in NULLIF, or to >> provide an operator alias that it gets dumped as? > This looks like a bug that'll want backpatching and it's not a data loss > risk, so I don't think it's urgent to shove this in before 9.4 closes. FWIW, I don't think this is something we ought to back-patch. NULLIF is effectively defined in terms of "a = b", where the = operator is whatever would be found by operator lookup. It's probably better to look for a default btree opclass, but that's a different behavior; and one that will have its own failure modes, particularly if a and b aren't of the same type. It is worth noting that the SQL standard says in so many words: NULLIF (V1, V2) is equivalent to the following <case specification>: CASE WHEN V1=V2 THEN NULL ELSE V1 END Now, you can argue about how literally they mean that; for one thing I doubt they want you to evaluate V1 twice. But nonetheless the construct is defined in terms of an operator named "=". Also, I think we still have some other dependencies on assumed operator names in eg. CASE. Cleaning up only NULLIF may not be a full solution. There have been past discussions of whether we ought to follow the letter or the spirit of the standard's references to "=" and other operators. Don't recall if we came to any definitive conclusions, but right now we're clearly not totally consistent on this point. regards, tom lane
В списке pgsql-bugs по дате отправления: