X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [64.117.225.181]) by svr1.postgresql.org (Postfix) with ESMTP id 20DFBD1C4C7 for ; Mon, 21 Jul 2003 16:03:54 +0000 (GMT) Received: from svr1.postgresql.org ([64.117.224.193]) by localhost (svr5.postgresql.org [64.117.225.181]) (amavisd-new, port 10024) with ESMTP id 20656-08 for ; Mon, 21 Jul 2003 16:03:43 +0000 (GMT) Received: from mx-00.sil.at (mx-00.sil.at [62.116.68.196]) by svr1.postgresql.org (Postfix) with ESMTP id 7076BD1C920 for ; Mon, 21 Jul 2003 13:03:42 -0300 (ADT) Received: (qmail-ldap/ctrl 14151 invoked from network); 21 Jul 2003 16:03:39 -0000 Received: from unknown (HELO waste.silverserver.co.at) ([194.152.178.7]) (envelope-sender ) by mx-00.sil.at (qmail-ldap-1.03) with SMTP for ; 21 Jul 2003 16:03:39 -0000 Received: from cybertec.at (vie-213-129-225-018.async.sil.at [213.129.225.18]) by waste.silverserver.co.at (8.12.9/8.12.8) with ESMTP id h6LG3UBr018782; Mon, 21 Jul 2003 18:03:31 +0200 Message-ID: <3F1C1192.5000205@cybertec.at> Date: Mon, 21 Jul 2003 18:15:14 +0200 From: =?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Conway Cc: Tom Lane , Bruce Momjian , Peter Eisentraut , =?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6?= =?ISO-8859-1?Q?nig?= , pgsql-hackers@postgresql.org, EG Subject: Re: dblink_ora - a first shot on Oracle ... References: <200307211339.h6LDdTR00206@candle.pha.pa.us> <4455.1058796993@sss.pgh.pa.us> <3F1BFD36.70200@joeconway.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200307/535 X-Sequence-Number: 41140 > I think for that very reason (SQL-MED) we need to come to terms with > this issue. If/when connections to external data sources is in the > backend, you'll have those exact same dependencies. And in fact, we do > today: consider '--with-openssl' or '--with-tcl'. > > I had always assumed we would need '--with-oracle', '--with-jdbc', etc > (or whatever you want to call them) to support backend connections to > external sources. And this discussion is the very reason I was hesitant > to pursue dblink_ora or jdbclink now, because I didn't think people > would be comfortable with configure options to support a contrib library. > > Joe If dblink was a core module I would say that adding the configure stuff would be very natural. Since this is contrib stuff I was not that sure about configure anymore. We will need additional flags for external data sources in the (hopefully) near future so I think we should add it. Personally I tend to think about a solution like that. dblink has a great future and many people simply love it (I cannot think of a customer who does not like it - it is a killer feature): - implement the concepts proposed by Joe on this list yesterday (I am talking about the functions dblink should provide) - add support to configure - merge dblink with dblink_ora as soon as the changes are ready - adapt jdbc_link and merge it with dblink - implement dblink_db2, dblink_csv, dblink_xml, and maybe some others - leave it in contrib because this way it will be shipped with the core distribution and people will use it more frequently I hope that I will finish the Oracle stuff (named connections, ...) within the next 3 days. Regards, Hans -- Cybertec Geschwinde u Schoenig Ludo-Hartmannplatz 1/14, A-1160 Vienna, Austria Tel: +43/2952/30706; +43/664/233 90 75 www.cybertec.at, www.postgresql.at, kernel.cybertec.at