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).
>
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
