[GENERAL] Outer joins
Can anyone confirm me that Postgres 7.1 does not support outer join ? Are functions similar to classical stored procedure ? thanks -- ** Eddie IANNUCCELLI - tel: 05 61 28 54 44 INRA, Laboratoire de Génétique Cellulaire Chemin de Borde Rouge - Auzeville -BP27 31326 Castanet Tolosan ** ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
RE: [GENERAL] Outer joins
Title: RE: [GENERAL] Outer joins Postgres 7.1 does support Left, right outer joins. Functions are similar to stored procedures but they cannot return rows. I think that this limitation is being worked on for the next release (7.2). By the way should there be a 'Postgres Features' page on the website. This would save a large amount of these queries and reduce the amount of e-mails on this list. I'm sure that lots of interest is being raised because of the 'Redhat Database' Announcement. Some of these people will just want to know what Postgres is capable of. Regards Ben -Original Message- From: eddie iannuccelli [mailto:[EMAIL PROTECTED]] Sent: 13 July 2001 18:51 Cc: [EMAIL PROTECTED] Subject: [GENERAL] Outer joins Can anyone confirm me that Postgres 7.1 does not support outer join ? Are functions similar to classical stored procedure ? thanks -- ** Eddie IANNUCCELLI - tel: 05 61 28 54 44 INRA, Laboratoire de Génétique Cellulaire Chemin de Borde Rouge - Auzeville -BP27 31326 Castanet Tolosan ** ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) Sorry about the footer it's automatic. * This email and any attachments transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender and do not store, copy or disclose the content to any other person. It is the responsibility of the recipient to ensure that opening this message and/or any of its attachments will not adversely affect its systems. No responsibility is accepted by the Company. *
Re: [GENERAL] Outer joins
eddie iannuccelli [EMAIL PROTECTED] writes: Can anyone confirm me that Postgres 7.1 does not support outer join ? What? It definitely *does* support outer joins. Are functions similar to classical stored procedure ? Depends on how loose your idea of similar is ... a function can't readily return a recordset at the moment. (This may be fixed in time for 7.2, though.) regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
RE: [GENERAL] Outer joins
I think there should be a Postgres Features section. It might be nice to have a concise comparison chart comparing its features with, for instance, MySQL, SQL Server 2000, Oracle, and any others that come up often in questions. The comparison chart should be frank while still unabashedly highlighting the many places where PostgreSQL really shines. You never know, some lazy journalist may decide to copy and paste it into their next review. ;--) Trewern, Ben [EMAIL PROTECTED] on 07/13/2001 10:06:41 AM To: [EMAIL PROTECTED] cc:(bcc: Wesley Sheldahl/Lex/Lexmark) Subject: RE: [GENERAL] Outer joins Postgres 7.1 does support Left, right outer joins. Functions are similar to stored procedures but they cannot return rows. I think that this limitation is being worked on for the next release (7.2). By the way should there be a 'Postgres Features' page on the website. This would save a large amount of these queries and reduce the amount of e-mails on this list. I'm sure that lots of interest is being raised because of the 'Redhat Database' Announcement. Some of these people will just want to know what Postgres is capable of. Regards Ben -Original Message- From: eddie iannuccelli [mailto:[EMAIL PROTECTED]] Sent: 13 July 2001 18:51 Cc: [EMAIL PROTECTED] Subject: [GENERAL] Outer joins Can anyone confirm me that Postgres 7.1 does not support outer join ? Are functions similar to classical stored procedure ? thanks -- ** Eddie IANNUCCELLI - tel: 05 61 28 54 44 INRA, Laboratoire de Génétique Cellulaire Chemin de Borde Rouge - Auzeville -BP27 31326 Castanet Tolosan ** ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) Sorry about the footer it's automatic. * This email and any attachments transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender and do not store, copy or disclose the content to any other person. It is the responsibility of the recipient to ensure that opening this message and/or any of its attachments will not adversely affect its systems. No responsibility is accepted by the Company. * ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [GENERAL] outer joins take forever
I believe Tom mentioned this sometime ago. If you are picking most of the rows then a seq_scan is preferable to a lookup through the index. In your case you are touching 100% of customer and almost 100% of neicstats, or at least that's what the optimizer thinks. Try vacuum_analyzing the tables in case the optimizer is fooled by older stats. cheers, t. On 31 May 2001, Seth wrote: I'm attempting to do an OUTER JOIN of two tables neicstats (6841 rows) customer(5062 rows) I'm using the command select * from neicstats left outer join customer on ( neicstats.cli_num = customer.cust_no ); which seems to run forever. I've created indexes on both cli_num and cust_no but 'explain' seems to indicate they're not being used - explain select * from neicstats left outer join customer on ( neicstats.cli_num = customer.cust_no ); NOTICE: QUERY PLAN: Nested Loop (cost=0.00..2297525.72 rows=285698 width=532) - Seq Scan on neicstats (cost=0.00..206.87 rows=6687 width=140) - Seq Scan on customer (cost=0.00..267.62 rows=5062 width=392) What methods can I use to speed up this query? Why does it take so long? ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] Outer Joins
Can someone explain why cname and date from table c gets printed in this query? Thanks. SELECT * FROM a FULL OUTER JOIN b USING (id) id | name | aname | name | bname | name | cname |date +--++--++--+-+ 1 | Bob | aname1 | Bob | bname1 | Bob | cname1 | 2001-01-07 2 | Jim | aname2 | Tom | bname2 | Jim | cname2 | 2001-01-07 9 | || || Tom | cname9 | 2001-01-07 10 | || || | cname10 | 2001-01-07 (4 rows) --- [ Charset ISO-8859-1 unsupported, converting... ] On Saturday 06 January 2001 20:21, Tom Lane wrote: "Robert B. Easter" [EMAIL PROTECTED] writes: What is the syntax for this? Is there an example I can see/run? SQL92 standard. See http://www.postgresql.org/devel-corner/docs/postgres/sql-select.htm for documentation (such as it is). There are some examples in the join regression test, too. regards, tom lane Thanks. I've tested out the cvs version and see that these joins appear to work: Qualified join: T1 INNER|[LEFT|RIGHT|FULL OUTER] JOIN T2 ON|USING() ... Natural join: T1 NATURAL INNER|[LEFT|RIGHT|FULL OUTER] JOIN T2 Cross join: T1 CROSS JOIN T2 But, Union join: T1 UNION JOIN T2 is not implemented. Nice! :) Here is a sample running of all this on cvs pgsql: CREATE TABLE a (id INTEGER, name TEXT, aname TEXT); CREATE TABLE b (id INTEGER, name TEXT, bname TEXT); CREATE TABLE c (id INTEGER, name TEXT, cname TEXT, date DATE DEFAULT CURRENT_DATE); INSERT INTO a VALUES (1, 'Bob', 'aname1'); INSERT INTO a VALUES (2, 'Jim', 'aname2'); INSERT INTO a VALUES (3, 'Tom', 'aname3'); INSERT INTO a VALUES (7, 'Joe', 'aname7'); INSERT INTO a VALUES (8, null, 'aname8'); INSERT INTO b VALUES (1, 'Bob', 'bname1'); INSERT INTO b VALUES (2, 'Tom', 'bname2'); INSERT INTO b VALUES (3, 'Joe', 'bname3'); INSERT INTO b VALUES (5, 'Jim', 'bname5'); INSERT INTO b VALUES (6, null, 'bname6'); INSERT INTO c VALUES (1, 'Bob', 'cname1'); INSERT INTO c VALUES (2, 'Jim', 'cname2'); INSERT INTO c VALUES (9, 'Tom', 'cname9'); INSERT INTO c VALUES (10, null, 'cname10'); -- Qualified Joins SELECT * FROM a JOIN b USING (id) JOIN c USING (id); SELECT * FROM a INNER JOIN b ON (a.id = b.id); SELECT * FROM a LEFT OUTER JOIN b USING(id, name); SELECT * FROM a RIGHT OUTER JOIN b USING (id); SELECT * FROM a FULL OUTER JOIN b USING (id) RIGHT OUTER JOIN c USING(id); -- Natural Joins SELECT * FROM a NATURAL INNER JOIN b; SELECT * FROM a NATURAL LEFT OUTER JOIN b; SELECT * FROM a NATURAL RIGHT OUTER JOIN b; SELECT * FROM a NATURAL FULL OUTER JOIN b; -- Cross Join SELECT * FROM a CROSS JOIN b; -- Union Join (not implemented, yet) SELECT * FROM a UNION JOIN b; The output is like this with cvs version: CREATE TABLE a (id INTEGER, name TEXT, aname TEXT); CREATE CREATE TABLE b (id INTEGER, name TEXT, bname TEXT); CREATE CREATE TABLE c (id INTEGER, name TEXT, cname TEXT, date DATE DEFAULT CURRENT_DATE); CREATE INSERT INTO a VALUES (1, 'Bob', 'aname1'); INSERT 21117 1 INSERT INTO a VALUES (2, 'Jim', 'aname2'); INSERT 21118 1 INSERT INTO a VALUES (3, 'Tom', 'aname3'); INSERT 21118 1 INSERT INTO a VALUES (7, 'Joe', 'aname7'); INSERT 21119 1 INSERT INTO a VALUES (8, null, 'aname8'); INSERT 21120 1 INSERT INTO b VALUES (1, 'Bob', 'bname1'); INSERT 21121 1 INSERT INTO b VALUES (2, 'Tom', 'bname2'); INSERT 21122 1 INSERT INTO b VALUES (3, 'Joe', 'bname3'); INSERT 21122 1 INSERT INTO b VALUES (5, 'Jim', 'bname5'); INSERT 21122 1 INSERT INTO b VALUES (6, null, 'bname6'); INSERT 21123 1 INSERT INTO c VALUES (1, 'Bob', 'cname1'); INSERT 21124 1 INSERT INTO c VALUES (2, 'Jim', 'cname2'); INSERT 21125 1 INSERT INTO c VALUES (9, 'Tom', 'cname9'); INSERT 21126 1 INSERT INTO c VALUES (10, null, 'cname10'); INSERT 21127 1 SELECT * FROM a JOIN b USING (id) JOIN c USING (id); id | name | aname | name | bname | name | cname |date +--++--++--++ 1 | Bob | aname1 | Bob | bname1 | Bob | cname1 | 2001-01-07 2 | Jim | aname2 | Tom | bname2 | Jim | cname2 | 2001-01-07 (2 rows) SELECT * FROM a INNER JOIN b ON (a.id = b.id); id | name | aname | id | name | bname +--+++--+ 1 | Bob | aname1 | 1 | Bob | bname1 2 | Jim | aname2 | 2 | Tom | bname2 3 | Tom | aname3 | 3 | Joe | bname3 (3 rows) SELECT * FROM a LEFT OUTER JOIN b USING(id, name); id | name | aname | bname +--++ 1 | Bob | aname1 | bname1 2 | Jim | aname2 | 3 | Tom | aname3 | 7 | Joe | aname7 | 8 | | aname8 | (5 rows) SELECT * FROM a RIGHT OUTER JOIN b USING (id); id | name | aname |
Re: [GENERAL] Outer Joins
Bruce Momjian [EMAIL PROTECTED] writes: Can someone explain why cname and date from table c gets printed in this query? Say what? test=# CREATE TABLE a (id INTEGER, name TEXT, aname TEXT); CREATE test=# CREATE TABLE b (id INTEGER, name TEXT, bname TEXT); CREATE test=# CREATE TABLE c (id INTEGER, name TEXT, cname TEXT, date DATE DEFAULT test(# CURRENT_DATE); CREATE test=# SELECT * FROM a FULL OUTER JOIN b USING (id); id | name | aname | name | bname +--+---+--+--- (0 rows) regards, tom lane
Re: [GENERAL] Outer Joins
Bruce Momjian [EMAIL PROTECTED] writes: Can someone explain why cname and date from table c gets printed in this query? Say what? test=# CREATE TABLE a (id INTEGER, name TEXT, aname TEXT); CREATE test=# CREATE TABLE b (id INTEGER, name TEXT, bname TEXT); CREATE test=# CREATE TABLE c (id INTEGER, name TEXT, cname TEXT, date DATE DEFAULT test(# CURRENT_DATE); CREATE test=# SELECT * FROM a FULL OUTER JOIN b USING (id); id | name | aname | name | bname +--+---+--+--- (0 rows) The text of the email showed this query returning columns from table c. Seems it was just a mistake in the email. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [GENERAL] Outer Joins
On Sunday 07 January 2001 00:53, Robert B. Easter wrote: Union join: T1 UNION JOIN T2 is not implemented. Nice! :) [snip] SELECT * FROM a UNION JOIN b; ERROR: UNION JOIN is not implemented yet psql:/home/reaster/sql/join/join.sql:37: ERROR: UNION JOIN is not implemented yet UNION JOIN is deprecated so maybe it doesn't need to be implemented? -- Robert B. Easter [EMAIL PROTECTED] - -- CompTechNews Message Board http://www.comptechnews.com/ -- -- CompTechServ Tech Services http://www.comptechserv.com/ -- -- http://www.comptechnews.com/~reaster/
Re: [GENERAL] Outer Joins
"Robert B. Easter" [EMAIL PROTECTED] writes: Just for the heck of it, I tried to execute all this sql on 7.0.3 and got this: psql:join2.sql:23: pqReadData() -- backend closed the channel unexpectedly. I knew it wouldn't run it, but didn't think it would crash. 7.0 had the beginnings of parser support for JOIN syntax, but there were bugs ... I think the one that you hit had to do with nested JOIN clauses, ie, a JOIN b JOIN c. regards, tom lane
Re: [GENERAL] Outer Joins
"Robert B. Easter" [EMAIL PROTECTED] writes: UNION JOIN is deprecated Oh? By whom? The reason 7.1 doesn't have it is I didn't have time for it, not that we don't plan to do it ever. regards, tom lane
Re: [GENERAL] Outer Joins
On Sunday 07 January 2001 13:13, Tom Lane wrote: "Robert B. Easter" [EMAIL PROTECTED] writes: UNION JOIN is deprecated Oh? By whom? The reason 7.1 doesn't have it is I didn't have time for it, not that we don't plan to do it ever. I read it in the SQL spec. ANSI/ISO 9075-2 1999 (final). Annex D (informative) Deprecated features It is intended that the following features will be removed at a later date from a revised version of this part of ISO/IEC 9075: 1) The ability to specify UNION JOIN in a joined table has been deprecated. It's the only one. I sent a patch to the patches list for JOIN documentation. In it, the only thing I said about UNION JOIN is "Deprecated." Let me know if I should change that. I thought about omitting it entirely. -- Robert B. Easter [EMAIL PROTECTED] - -- CompTechNews Message Board http://www.comptechnews.com/ -- -- CompTechServ Tech Services http://www.comptechserv.com/ -- -- http://www.comptechnews.com/~reaster/
Re: [GENERAL] Outer Joins
"Robert B. Easter" [EMAIL PROTECTED] writes: UNION JOIN is deprecated Oh? By whom? I read it in the SQL spec. ANSI/ISO 9075-2 1999 (final). It is intended that the following features will be removed at a later date from a revised version of this part of ISO/IEC 9075: 1) The ability to specify UNION JOIN in a joined table has been deprecated. Interesting. Maybe we won't ever bother to do it, then. regards, tom lane
Re: [GENERAL] Outer Joins
What is the syntax for this? Is there an example I can see/run? On Thursday 04 January 2001 04:30, Poul L. Christiansen wrote: PostgreSQL 7.1 (which is in beta now) will have outer joins. It will probably (and hopefully) be released in Jan./Feb., but the beta seems quite stable to me. Poul L. Christiansen Michael Dunn wrote: I am relatively new to the list and somewhat new to PostgreSQL. I am wondering if there has been any discussion or thought about including outer joins in later releases of PostreSQL. It seems highly inefficient simulating outer joins with subqueries and UNION ALL statements. Or, perhaps PostgreSQL has another way prevent unjoined rows from being supressed in the results. Your comments are welcome. Thanks, Micael Dunn -- Robert B. Easter [EMAIL PROTECTED] - -- CompTechNews Message Board http://www.comptechnews.com/ -- -- CompTechServ Tech Services http://www.comptechserv.com/ -- -- http://www.comptechnews.com/~reaster/
Re: [GENERAL] Outer Joins
"Robert B. Easter" [EMAIL PROTECTED] writes: What is the syntax for this? Is there an example I can see/run? SQL92 standard. See http://www.postgresql.org/devel-corner/docs/postgres/sql-select.htm for documentation (such as it is). There are some examples in the join regression test, too. regards, tom lane
Re: [GENERAL] Outer Joins
On Sat, 6 Jan 2001, Robert B. Easter wrote: What is the syntax for this? Is there an example I can see/run? Should follow standard SQL92 syntax (which, BTW, Oralce doesn't): SELECT * FROM table1 LEFT OUTER JOIN table2 ON (table1.field = table2.field) This will return all rows from table1 even if no corresponding row exists in table2. A RIGHT OUTER JOIN would do the opposite. -- Brett http://www.chapelperilous.net/~bmccoy/ --- It is better to have loved a short man than never to have loved a tall.
Re: [GENERAL] Outer Joins
On Saturday 06 January 2001 20:21, Tom Lane wrote: "Robert B. Easter" [EMAIL PROTECTED] writes: What is the syntax for this? Is there an example I can see/run? SQL92 standard. See http://www.postgresql.org/devel-corner/docs/postgres/sql-select.htm for documentation (such as it is). There are some examples in the join regression test, too. regards, tom lane Thanks. I've tested out the cvs version and see that these joins appear to work: Qualified join: T1 INNER|[LEFT|RIGHT|FULL OUTER] JOIN T2 ON|USING() ... Natural join: T1 NATURAL INNER|[LEFT|RIGHT|FULL OUTER] JOIN T2 Cross join: T1 CROSS JOIN T2 But, Union join: T1 UNION JOIN T2 is not implemented. Nice! :) Here is a sample running of all this on cvs pgsql: CREATE TABLE a (id INTEGER, name TEXT, aname TEXT); CREATE TABLE b (id INTEGER, name TEXT, bname TEXT); CREATE TABLE c (id INTEGER, name TEXT, cname TEXT, date DATE DEFAULT CURRENT_DATE); INSERT INTO a VALUES (1, 'Bob', 'aname1'); INSERT INTO a VALUES (2, 'Jim', 'aname2'); INSERT INTO a VALUES (3, 'Tom', 'aname3'); INSERT INTO a VALUES (7, 'Joe', 'aname7'); INSERT INTO a VALUES (8, null, 'aname8'); INSERT INTO b VALUES (1, 'Bob', 'bname1'); INSERT INTO b VALUES (2, 'Tom', 'bname2'); INSERT INTO b VALUES (3, 'Joe', 'bname3'); INSERT INTO b VALUES (5, 'Jim', 'bname5'); INSERT INTO b VALUES (6, null, 'bname6'); INSERT INTO c VALUES (1, 'Bob', 'cname1'); INSERT INTO c VALUES (2, 'Jim', 'cname2'); INSERT INTO c VALUES (9, 'Tom', 'cname9'); INSERT INTO c VALUES (10, null, 'cname10'); -- Qualified Joins SELECT * FROM a JOIN b USING (id) JOIN c USING (id); SELECT * FROM a INNER JOIN b ON (a.id = b.id); SELECT * FROM a LEFT OUTER JOIN b USING(id, name); SELECT * FROM a RIGHT OUTER JOIN b USING (id); SELECT * FROM a FULL OUTER JOIN b USING (id) RIGHT OUTER JOIN c USING(id); -- Natural Joins SELECT * FROM a NATURAL INNER JOIN b; SELECT * FROM a NATURAL LEFT OUTER JOIN b; SELECT * FROM a NATURAL RIGHT OUTER JOIN b; SELECT * FROM a NATURAL FULL OUTER JOIN b; -- Cross Join SELECT * FROM a CROSS JOIN b; -- Union Join (not implemented, yet) SELECT * FROM a UNION JOIN b; The output is like this with cvs version: CREATE TABLE a (id INTEGER, name TEXT, aname TEXT); CREATE CREATE TABLE b (id INTEGER, name TEXT, bname TEXT); CREATE CREATE TABLE c (id INTEGER, name TEXT, cname TEXT, date DATE DEFAULT CURRENT_DATE); CREATE INSERT INTO a VALUES (1, 'Bob', 'aname1'); INSERT 21117 1 INSERT INTO a VALUES (2, 'Jim', 'aname2'); INSERT 21118 1 INSERT INTO a VALUES (3, 'Tom', 'aname3'); INSERT 21118 1 INSERT INTO a VALUES (7, 'Joe', 'aname7'); INSERT 21119 1 INSERT INTO a VALUES (8, null, 'aname8'); INSERT 21120 1 INSERT INTO b VALUES (1, 'Bob', 'bname1'); INSERT 21121 1 INSERT INTO b VALUES (2, 'Tom', 'bname2'); INSERT 21122 1 INSERT INTO b VALUES (3, 'Joe', 'bname3'); INSERT 21122 1 INSERT INTO b VALUES (5, 'Jim', 'bname5'); INSERT 21122 1 INSERT INTO b VALUES (6, null, 'bname6'); INSERT 21123 1 INSERT INTO c VALUES (1, 'Bob', 'cname1'); INSERT 21124 1 INSERT INTO c VALUES (2, 'Jim', 'cname2'); INSERT 21125 1 INSERT INTO c VALUES (9, 'Tom', 'cname9'); INSERT 21126 1 INSERT INTO c VALUES (10, null, 'cname10'); INSERT 21127 1 SELECT * FROM a JOIN b USING (id) JOIN c USING (id); id | name | aname | name | bname | name | cname |date +--++--++--++ 1 | Bob | aname1 | Bob | bname1 | Bob | cname1 | 2001-01-07 2 | Jim | aname2 | Tom | bname2 | Jim | cname2 | 2001-01-07 (2 rows) SELECT * FROM a INNER JOIN b ON (a.id = b.id); id | name | aname | id | name | bname +--+++--+ 1 | Bob | aname1 | 1 | Bob | bname1 2 | Jim | aname2 | 2 | Tom | bname2 3 | Tom | aname3 | 3 | Joe | bname3 (3 rows) SELECT * FROM a LEFT OUTER JOIN b USING(id, name); id | name | aname | bname +--++ 1 | Bob | aname1 | bname1 2 | Jim | aname2 | 3 | Tom | aname3 | 7 | Joe | aname7 | 8 | | aname8 | (5 rows) SELECT * FROM a RIGHT OUTER JOIN b USING (id); id | name | aname | name | bname +--++--+ 1 | Bob | aname1 | Bob | bname1 2 | Jim | aname2 | Tom | bname2 3 | Tom | aname3 | Joe | bname3 5 | || Jim | bname5 6 | || | bname6 (5 rows) SELECT * FROM a FULL OUTER JOIN b USING (id) id | name | aname | name | bname | name | cname |date +--++--++--+-+ 1 | Bob | aname1 | Bob | bname1 | Bob | cname1 | 2001-01-07 2 | Jim | aname2 | Tom | bname2 | Jim | cname2 | 2001-01-07 9 | || || Tom | cname9 | 2001-01-07 10 | || || | cname10 | 2001-01-07 (4 rows) SELECT * FROM a NATURAL INNER JOIN b; id | name | aname | bname +--++ 1 | Bob | aname1 | bname1 (1
[GENERAL] Outer joins
Going through the documentation I can only find little about outer joins. One statement is in the Changes doc about including syntax for outer joins, but there doesn't seem to be implemented any code after that. Is it true that there's no outer joins yet? Any plans? Btw. what is the syntax for outer joins. I know only Oracle's (+) operator.
