Re: BUG #3822: Nonstandard precedence for comparison operators

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Pedro Gimeno <pgsql-001(at)personal(dot)formauri(dot)es>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #3822: Nonstandard precedence for comparison operators
Date: 2008-03-21 19:58:03
Message-ID: 200803211958.m2LJw3C14621@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs


Added to TODO:

* Fix inconsistent precedence of =, >, and < compared to <>, >=, and <=

http://archives.postgresql.org/pgsql-bugs/2007-12/msg00145.php

---------------------------------------------------------------------------

Pedro Gimeno wrote:
> Tom Lane wrote:
>
> > "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> >> That said, bringing PostgreSQL into compliance with the standard
> >> would undoubtedly break some people's existing applications.
>
> I wonder how that compares to broken queries while migrating databases
> from other systems. I'd bet there are more of the latter. We ran into
> that while running a query like: SELECT ... WHERE column <>
> another_column || 'literal';, variants of which I think can be
> relatively common compared to e.g. applications that build a boolean
> array using expr1 <> expr2 || boolean_value.
>
> > The spec seems to barely have a notion of operator precedence at all ---
>
> The precedence is given by the parse tree and is well defined. Perhaps
> it may vary for a given operator depending on the context but it's
> clearly different to the one PostgreSQL is using in the examples I gave.
>
> > for example, all the variants of <predicate> are at the same precedence
> > level, and if I'm reading it right they actively disallow ambiguous
> > cases by requiring parentheses; note the way that <boolean primary>
> > is defined. This entire arrangement breaks down as soon as you consider
> > user-defined operators that yield boolean results. So I'm not
> > particularly excited about the idea of slavish compliance with the spec
> > in this area.
>
> Note that we considered PostgreSQL precisely because of its high
> standards compliance and this problem has been a bit disappointing, even
> more given that I looked for information on what nonstandard bits did
> PostgreSQL have and didn't see this.
>
> In the case of user defined operators I'd expect them to have a fixed
> precedence regardless of the semantics and that can be different
> depending on the operator.
>
> > Given that it's been this way for ten years and no one has complained
> > before, I'm disinclined to change it, and even more disinclined to
> > invest the effort that would be involved in letting the behavior vary
> > at runtime.
>
> It has often happened that a new version has caused the need of porting
> code, that's not new. Users will very likely appreciate compliance with
> the standard even with the hassle of porting the applications, specially
> when the fixes, if they're necessary, can easily be made backwards
> compatible by using parentheses. For that reason I don't think a runtime
> selection of behaviour would be neecessary in this case.
>
> -- Pedro Gimeno
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Bruce Momjian 2008-03-22 01:33:00 Re: BUG #3833: Index remains when table is dropped
Previous Message Bruce Momjian 2008-03-21 19:49:10 Re: Server does not start when log_statement_stats is set to on