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
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
