On Mon, 2011-06-20 at 10:00 +0930, Pilling, Michael wrote:
> The behaviour of the generated code may well be correct and indeed I
> agree that it is but from
> everything you and the detailed documentation have said column != NULL
> is at least deprecated
> and is highly likely to indicate a progra
On 20/06/2011 8:30 AM, Pilling, Michael wrote:
I was looking at that page but didn't read the detail because I thought
the information was in the table and the detail was just textual examples.
I do think that adding "IS DISTINCT FROM" and "IS NULL / IS NOT NULL" to
the summary table would be
On 20/06/2011 7:43 AM, Pilling, Michael wrote:
Thanks Craig,
The real problem here then is that the documentation showing
the boolean comparison operators does not mention this quirk, which I
accept may be a standard quirk but it's still a quirk.
What URL are you looking at?
http://www.postgr
>> The real problem here then is that the documentation showing
>> the boolean comparison operators does not mention this
> This page does, at length:
But not in the table, in fact it doesn't even mention the IS NULL, IS NOT NULL
operators at all.
>http://www.postgresql.org/docs/9.0/intera
Hi Kevin,
Thanks for that. Point entirely taken. I think what I would add would be in the
table 9-1 of operators,
an extra column filled in only for =, <> and != saying Important: see
difference from IS [NOT] NULL.
Perhaps one reason I didn't pick up on this subtle issue is that IS NULL and IS
Thanks Craig,
The real problem here then is that the documentation showing
the boolean comparison operators does not mention this quirk, which I
accept may be a standard quirk but it's still a quirk. You just
wouldn't go looking for that flag unless you had any inkling that
it might exist.
And i
"Pilling, Michael" wrote:
> The real problem here then is that the documentation showing
> the boolean comparison operators does not mention this
This page does, at length:
http://www.postgresql.org/docs/9.0/interactive/functions-comparison.html
What page are you looking at?
> And indeed
On 6/19/11, Tom Lane wrote:
> "Jeff Janes" writes:
>> Starting with commit b4b6923e03f4d29636a94f6f4cc2f5cf6298b8c8,
>> "Fix VACUUM so that it always updates pg_class.reltuples/relpages."
>
>> After running make installcheck, the tables regression.public.slow_emp4000
>> and regression.public.fast
"Jeff Janes" writes:
> After running make installcheck, the tables regression.public.slow_emp4000
> and regression.public.fast_emp4000 get analyzed once a minute even though
> they have no activity. None of the other installcheck tables, just those
> two.
Oh, wait, I see what's different about t
On Sat, 2011-06-18 at 13:20 -0700, Jeff Davis wrote:
> Interesting problem... the bug is in get_op_btree_interpretation() which
> has code like this:
>
> /*
>
>* If we can't find any opfamily co
"Jeff Janes" writes:
> Starting with commit b4b6923e03f4d29636a94f6f4cc2f5cf6298b8c8,
> "Fix VACUUM so that it always updates pg_class.reltuples/relpages."
> After running make installcheck, the tables regression.public.slow_emp4000
> and regression.public.fast_emp4000 get analyzed once a minute
On 06/17/2011 10:20 PM, Kevin Grittner wrote:
"Michael Pilling" wrote:
A reasonable programmer would expect != NULL,<> NULL and IS NOT
NULL to be synonyms.
Only if that programmer was not aware of the SQL standard and had
not worked much with a standard-conforming database.
Yep, and if th
12 matches
Mail list logo
