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" <[E
Pedro Gimeno wrote:
> > 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
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Pedro Gimeno wrote:
> Tom Lane wrote:
>
> > "Kevin Grittner" <[EMAIL PROTECTED]> writes:
> >> That said, bringing Po
Tom Lane wrote:
> Michael Glaesemann <[EMAIL PROTECTED]> writes:
>> I'm probably being dense, but I don't see how this is an issue.
>
> That's just a bug in his example ;-)
Right, sorry. I meant boolean_array rather than boolean_value:
=> SELECT 'a' <> 'a' || '{true}';
?column?
--
{f,t
Michael Glaesemann <[EMAIL PROTECTED]> writes:
> I'm probably being dense, but I don't see how this is an issue.
That's just a bug in his example ;-)
The real question is whether there is enough of a problem here to
justify creating new problems, in the form of backwards-compatibility
hazards. O
On Dec 29, 2007, at 14:09 , Pedro Gimeno wrote:
variants of which I think can be
relatively common compared to e.g. applications that build a boolean
array using expr1 <> expr2 || boolean_value.
I'm probably being dense, but I don't see how this is an issue. || is
string concatenation, not
Tom Lane wrote:
> "Kevin Grittner" <[EMAIL PROTECTED]> 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 the
>>> On Thu, Dec 27, 2007 at 4:22 PM, in message <[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
> "Kevin Grittner" <[EMAIL PROTECTED]> writes:
> To the extent that you do believe the spec, there are more problems with
> our precedence rules than just where <= fits --- it looks to me lik
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> That said, bringing PostgreSQL into compliance with the standard
> would undoubtedly break some people's existing applications.
The spec seems to barely have a notion of operator precedence at all ---
for example, all the variants of are at the same
>>> On Mon, Dec 17, 2007 at 1:58 PM, in message
<[EMAIL PROTECTED]>, "Pedro Gimeno"
<[EMAIL PROTECTED]> wrote:
> Description:Nonstandard precedence for comparison operators
> The operators <>, <= and >= are expected to have the same precedence as =, <
> and >, but according to the doc
The following bug has been logged online:
Bug reference: 3822
Logged by: Pedro Gimeno
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.5
Operating system: Any
Description:Nonstandard precedence for comparison operators
Details:
The operators <>, <= and >= ar
11 matches
Mail list logo