Re: dblink_ora - a first shot on Oracle ...

> 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