From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(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 14:48:22 |
Message-ID: | 3F1BFD36.70200@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> I tend to agree with Peter: if dblink is going to start depending on
> stuff outside Postgres, it ought to be become a separate project,
> if only to simplify distribution and configuration issues.
>
> Perhaps it could be split into two parts, a PG-specific part and
> a cross-DBMS part?
>
> regards, tom lane
>
> PS: Has anyone looked any further at the SQL-MED standard? ISTM that's
> where we ought to head in the long run.
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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2003-07-21 15:09:31 | Re: dblink_ora - a first shot on Oracle ... |
Previous Message | Tom Lane | 2003-07-21 14:16:33 | Re: dblink_ora - a first shot on Oracle ... |