From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Hans-Jürgen Schönig <hs(at)cybertec(dot)at> |
Cc: | Joe Conway <mail(at)joeconway(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Hans-Jürgen Schönig <postgres(at)cybertec(dot)at>, pgsql-hackers(at)postgresql(dot)org, EG <EG(at)cybertec(dot)at> |
Subject: | Re: dblink_ora - a first shot on Oracle ... |
Date: | 2003-07-21 16:13:39 |
Message-ID: | 200307211613.h6LGDdM17129@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hans, I am a little confused about what you are suggesting. Are you
suggesting flag to the make of the contrib module rather than configure
tests?
I agree this is a killer feature for many people and would like to have
it in 7.4.
---------------------------------------------------------------------------
Hans-Jrgen Schnig wrote:
> > 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
>
>
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Hans-Jürgen Schönig | 2003-07-21 16:15:14 | Re: dblink_ora - a first shot on Oracle ... |
Previous Message | Hans-Jürgen Schönig | 2003-07-21 15:57:40 | Re: PostgreSQL 7.3.3 and Intel C compiler |