Re: BUG #3778: Natural join with filter problem

From: Laurent HERVE <laurentjpherve(at)orange(dot)fr>
To: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
Cc: PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #3778: Natural join with filter problem
Date: 2007-11-26 13:47:32
Message-ID: 1196084852.10051.17.camel@tatooine
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

ok thank you... and sorry for not having checked enough time in the
documentation.
anyway, i think a kind of JOIN ... USING (primary key columns) could be
useful.
if you change a primary key, because of design choice, you won't have to
rewrite all rules and views for example, just simple execute would be
required. This is why i used NATURAL.
ok, i will use the INNER JOIN ... USING as suggested.
regards
laurent Herve

Le lundi 26 novembre 2007 à 12:55 +0000, Heikki Linnakangas a écrit :
> Please keep the list CC'd.
>
> Laurent HERVE wrote:
> > in fact, i don't know why the column "code_document" is used because it
> > is not in the primary key of the tables.
> > So as this column is nullable, it gives unexpected results.
> >
> > I thought only the columns on the primary key are taken into account
> > when building a join. Maybe i misunderstood something in how postgresql
> > builds the join.
>
> Ah, no. According to the docs:
>
> NATURAL is shorthand for a USING list that mentions all columns in
> the two tables that have the same names.
>
> Because there's a column called code_document in both tables, you'll
> have to use an INNER JOIN to get what you want. If you want to eliminate
> the duplicate columns from the result set like a NATURAL JOIN does, you
> can use INNER JOIN ... USING (list of columns).
>

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Heikki Linnakangas 2007-11-26 13:56:16 Re: BUG #3778: Natural join with filter problem
Previous Message Heikki Linnakangas 2007-11-26 12:55:16 Re: BUG #3778: Natural join with filter problem