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
