There seems to be some disagreement on whether the Oracle lib checks
should be in configure for a /contrib module, and I don't know how far
Hans is. I will say we are probably looking at 7/28 for beta.
I am afraid I won't make it until 7.4beta1.
The problem is that I have not managed to have mor
Josh Berkus wrote:
> Hans, Bruce,
>
> We're drafting the press release for 7.4 right now. What's the odds that
> dblink_ora will be ready in time for 7.4?
There seems to be some disagreement on whether the Oracle lib checks
should be in configure for a /contrib module, and I don't know how far
Hans, Bruce,
We're drafting the press release for 7.4 right now. What's the odds that
dblink_ora will be ready in time for 7.4?
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 5: Have you checked our extensive
Bruce Momjian wrote:
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.
Under these circumstances I was thinking of i
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 '--
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.
-
On 7/21/2003 9:16 AM, Tom Lane wrote:
>Bruce Momjian <[EMAIL PROTECTED]> writes:
>
>
>>I don't see the problem.
>>
>>
>
>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 a
Joe Conway wrote:
> > 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'l
Joe Conway writes:
> 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.
No, SQL-MED is a framework to plug in different connectors -- exactly what
some are
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?
re
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I don't see the problem.
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
Rod Taylor wrote:
-- Start of PGP signed section.
> > I don't see the problem.
>
> How about a (simple!) configure process in the dblink directory only
> which detects the various items.
I thought of that but configure seems so confusing that setting up
another on in a contrib directory seemed pr
> I don't see the problem.
How about a (simple!) configure process in the dblink directory only
which detects the various items.
signature.asc
Description: This is a digitally signed message part
Of course, PostgreSQL will still install without the Oracle libraries.
Of course, if you want dblink to use Oracle libraries, you have to
install the Oracle libraries first, or rerun configure after you install
them and reinstall dblink.
I don't see the problem.
---
Bruce Momjian writes:
> Joe, I can do the configure detection of the Oracle library needed for
> /contrib.
I have a philosophical problem with putting Oracle detection code into the
PostgreSQL build system. That way, you create a dependency that Oracle
needs to be installed before you install Po
Bruce Momjian wrote:
Joe, I can do the configure detection of the Oracle library needed for
/contrib. I don't think we follow the beta freeze as much for /contrib
stuff, but this particular /contrib is more integrated into the main
system than most. If you want to merge it in during the next mont
One reason I am excited about an Oracle-enabled dblink is that it gives
us a seamless way for PostgreSQL to operate in an evironment with
multiple database products, which I think is important.
As far as the Oracle libraries, once you have an Oracle-enabled patch in
CVS, I will put a some value i
Hans-Jürgen Schönig wrote:
Thanks a lot. I will integrate named connections as proposed by the most
recent version of dblink as soon as possible.
Thanks for doing the configure stuff. What we need is Oracle's OCI
interface and libsqlora (http://www.poitschke.de/libsqlora8/).
I was thinking that w
Joe, I can do the configure detection of the Oracle library needed for
/contrib. I don't think we follow the beta freeze as much for /contrib
stuff, but this particular /contrib is more integrated into the main
system than most. If you want to merge it in during the next month, I
can do the conf
Joe Conway wrote:
Bruce Momjian wrote:
OK, can you take ownership of it?
You mean a TODO entry? Sure, as long as Hans is OK with it.
Joe
I am ok with it.
The only problem I have at the moment is that I don't know how to build
properly and to check for the libs needed by Oracle.
The entire co
Joe Conway <[EMAIL PROTECTED]> writes:
> Yeah. But we'd need to detect whether or not the Oracle client libs are
> available. I'm not sure how to do that with the contrib build system.
> And we'd need a fair amount of integration/reorganizing the existing
> code. Also, I've got the same issues w
Bruce Momjian wrote:
Well, we have a patch, so we need someone to babysit it until it is
applied, or put it somewhere and reference it via TODO.
OK -- either way is fine by me.
Joe
---(end of broadcast)---
TIP 6: Have you searched our list archive
Well, we have a patch, so we need someone to babysit it until it is
applied, or put it somewhere and reference it via TODO.
---
Joe Conway wrote:
> Bruce Momjian wrote:
> > OK, can you take ownership of it?
> >
>
> You mea
Bruce Momjian wrote:
OK, can you take ownership of it?
You mean a TODO entry? Sure, as long as Hans is OK with it.
Joe
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to
OK, can you take ownership of it?
---
Joe Conway wrote:
> Bruce Momjian wrote:
> > This seems like a natural addition to our existing dblink in /contrib.
> >
>
> Yeah. But we'd need to detect whether or not the Oracle clie
Bruce Momjian wrote:
This seems like a natural addition to our existing dblink in /contrib.
Yeah. But we'd need to detect whether or not the Oracle client libs are
available. I'm not sure how to do that with the contrib build system.
And we'd need a fair amount of integration/reorganizing the ex
This seems like a natural addition to our existing dblink in /contrib.
---
Hans-Jürgen Schönig wrote:
> Hi there ...
>
> I have spent some time working on an Oracle version of dblink. It works
> quite nicely for me and I h
Hi there ...
I have spent some time working on an Oracle version of dblink. It works
quite nicely for me and I hope it does for others.
It already supports some basic features such as persistent connection
and fetching data. This is not a perfect piece of software and there is
lot of room for
28 matches
Mail list logo
