Re: [SQL] Question about a CIDR based query

George, > Um, no, I need an EXPLAIN ANALYZE, not just an EXPLAIN. Thanks. > > > June_03=# explain select * from tmp where route >>='62.1.1.0/24'; > >QUERY PLAN > > > > Seq Scan on tmp (cost=0.00..606.6

Re: [SQL] Question about a CIDR based query

George, Um, no, I need an EXPLAIN ANALYZE, not just an EXPLAIN. Thanks. > June_03=# explain select * from tmp where route >>='62.1.1.0/24'; >QUERY PLAN > > Seq Scan on tmp (

Re: [SQL] OUTER JOIN problem

On Wed, 23 Jun 2004, Zoltan Boszormenyi wrote: > I don't know how PostgreSQL works internally but this bug *must* be > conforming to some standard if two distinct SQL server products behave > (almost) the same. I said almost, I discovered the same annoyance today > on an Informix 9.21 running und

[SQL] OUTER JOIN problem

Hi, I have a problem with LEFT OUTER JOIN, not only in PostgreSQL but in Informix, too. I thought someone can explain the "bug" I am seeing. Let me qoute my psql session, forgive me, it's a bit long: $ LANG=C psql -h localhost -U postgres postgres Welcome to psql 7.3.4-RH, the PostgreSQL interactiv

Re: FW: [SQL] "=" operator vs. "IS"

Stephan Szabo <[EMAIL PROTECTED]> writes: > IS TRUE and IS FALSE have a different effect from =true and =false when > the left hand side is NULL. The former will return false, the latter will > return NULL. No, actually they both return false. (But thanks, I didn't even realize they were specia

Re: FW: [SQL] "=" operator vs. "IS"

Rich Hall <[EMAIL PROTECTED]> writes: > "(anything) = NULL" is always Null, this cannot be what the coder intended. I often have such things in my SQL. Consider what happens when you have SQL constructed dynamically. Or more frequently, consider that many drivers still don't use the new binary pl

Re: FW: [SQL] "=" operator vs. "IS"

On Tue, 29 Jun 2004, Greg Stark wrote: > Stephan Szabo <[EMAIL PROTECTED]> writes: > > > IS TRUE and IS FALSE have a different effect from =true and =false when > > the left hand side is NULL. The former will return false, the latter will > > return NULL. > > No, actually they both return false.

Re: [SQL] UPDATE ... WHERE (subselect on the same table)

"Alexander M. Pravking" <[EMAIL PROTECTED]> writes: > fduch=# UPDATE test SET x = 't' > fduch-# where typ = 1 and exists ( > fduch(# SELECT 1 from test t2 > fduch(# where t2.typ = 2 and t2.name = test.name > fduch(# ); > So I have two questions: > Q1, cognitive. Why the alias for the updated table

Re: [SQL] UPDATE ... WHERE (subselect on the same table)

On Tue, Jun 29, 2004 at 12:49:55PM -0400, Tom Lane wrote: > > So I have two questions: > > Q1, cognitive. Why the alias for the updated table is restricted? > > Because the SQL standard doesn't allow an alias there. We've talked > about allowing one anyway, but no one's gotten around to it. AFAI

Re: FW: [SQL] "=" operator vs. "IS"

Rich Hall wrote: > My question is why is the form > > "(anything) = NULL" > > allowed? > > Since > > "(anything) = NULL" is always Null, this cannot be what the coder > intended. Using that same line of argument, why is 1+1 allowed? The coder clearly knows that it is 2, so why is he writing that

[SQL] test1

2,3,4,5 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org

[SQL] UPDATE ... WHERE (subselect on the same table)

I was looking for how can I give an alias for the table being updated (something like UPDATE table_name table_alias SET ...), but the current syntax doesn't allow that. What I need is to: fduch=# SELECT * from test order by typ, name; typ | name | x -+--+--- 1 | bar | 1 | baz |

Re: [SQL] Unrecognized node type

Alvaro Sanchez-Mariscal <[EMAIL PROTECTED]> writes: > I've tried to import a dump from pg_dump. Everything goes ok, but at > certain point, in the following sentence: > CREATE TABLE ca_persona ( > ... > lssi boolean DEFAULT NULL::boolean, > postal boolean DEFAULT NULL::boolean, > tele

[SQL] Unrecognized node type

Hi: I've to import a DB schema and data from one pgsql to another. The source version is 7.3.4. The destination version is 7.4.2. I've tried to import a dump from pg_dump. Everything goes ok, but at certain point, in the following sentence: CREATE TABLE ca_persona ( ... lssi boolean DEFAULT

Re: FW: [SQL] "=" operator vs. "IS"

NULL is handled like "unknow" When you comparing something with an unknown value, you are not able to say if they are equal or not. So the result is also unknown. The result NULL is correct. If you whant to check if somethings is NULL you have to use "(anything) IS NULL" Rich Hall schrieb: My ques

Re: FW: [SQL] "=" operator vs. "IS"

Rich Hall <[EMAIL PROTECTED]> writes: > My question is why is the form > "(anything) = NULL" > allowed? If you think it shouldn't be, you can turn on the transform_null_equals flag. However, past experience has shown that that breaks more things than it fixes. In any case, few people like to dep

Re: FW: [SQL] "=" operator vs. "IS"

My question is why is the form "(anything) = NULL" allowed? Since "(anything) = NULL" is always Null, this cannot be what the coder intended. This is much different when comparing two variables, where the coder may have to handle the cases where the variables are Null. Here the comparison is to

Re: [SQL] finding if a foreign key is in use

Kenneth Gonsalves <[EMAIL PROTECTED]> wrote: > in my app i have a table where the id serves as a foreign key for > one or more other tables. if i want to delete a row in the table, > i currently search the other tables where this table is referenced > to see if the row is in use - and then, if not