Re: BUG #3778: Natural join with filter problem
От | Laurent HERVE |
---|---|
Тема | Re: BUG #3778: Natural join with filter problem |
Дата | |
Msg-id | 1196084852.10051.17.camel@tatooine обсуждение исходный текст |
Ответ на | Re: BUG #3778: Natural join with filter problem (Heikki Linnakangas <heikki@enterprisedb.com>) |
Ответы |
Re: BUG #3778: Natural join with filter problem
|
Список | 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). >
В списке pgsql-bugs по дате отправления: