> 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
