Re: Precedence of standard comparison operators
От | Kevin Grittner |
---|---|
Тема | Re: Precedence of standard comparison operators |
Дата | |
Msg-id | 998349574.2846821.1424449228807.JavaMail.yahoo@mail.yahoo.com обсуждение исходный текст |
Ответ на | Precedence of standard comparison operators (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Precedence of standard comparison operators
|
Список | pgsql-hackers |
Tom Lane <tgl@sss.pgh.pa.us> wrote: > the precedence of <= >= and <> is neither sane nor standards compliant. +1 That was a bit of a pain when I migrated a lot of code from Sybase ASE to PostgreSQL; I think we should conform to the standard on this, even if it breaks backward compatibility. (Of course, the release notes must warn about this in a conspicuous way.) > We have that right for = < > but not for the other three standard-mandated > comparison operators. I think we should change the grammar so that all > six act like < > do now, that is, they should have %nonassoc precedence > just above NOT. +1 > Another thought, looking at this closely, is that we have the precedence > of IS tests (IS NOT NULL etc) wrong as well: they should bind less tightly > than user-defined ops, not more so. I'm less excited about changing that, > but there's certainly room to argue that it's wrong per spec. It's > definitely weird that the IS tests bind more tightly than multicharacter > Ops but less tightly than + - * /. Again, I think it is worth it to conform to the standard. > I've not really experimented with this at all; it would be useful for > example to see how many regression tests break as a gauge for how > troublesome such changes would be. I thought I'd ask whether there's > any chance at all of such a change getting accepted before doing any > serious work on it. You will have my vote. I wonder whether it would be feasible to have an option to generate warnings (or maybe just LOG level messages?) for queries where the results could differ. (I seem to remember some queries that, when written to standard and run on PostgreSQL, silently returned results incompatible with the standard. We changed the code to generate SQL to emit extra layers of parentheses to get the same behavior on both databases, but we had to notice the problem first.) -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: