From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Darko Prenosil <darko(dot)prenosil(at)finteh(dot)hr> |
Cc: | hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [GENERAL] One SQL to access two databases. |
Date: | 2002-11-30 21:11:20 |
Message-ID: | 3DE92978.20604@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Darko Prenosil wrote:
> Now when the 7.3 release is out,can we get back to plpq ?
> I did send You sources before vacation, and You said that You will take a
> look.
> I hope I am not disturbing You. If You think that this is bad Idea, I give up
> hope that we merge this functions into dblink, an I will do it manually for
> my projects as I did before(I must say that this is a frustration for me
> because I must tweak the code with every new release of postgres).
> I am not using new plpq functions jet, so even if You do not want to merge,
> maybe You can give me some comments(as I said before, I do not understand
> memory management and memory contests to well) ?
> Thank You in advance.
>
I'm still interested in merging the plpq functions into dblink. As I said
before, particularly now that plpgsql can returns sets, I think these
functions are very useful.
There are several other changes I'd like to make to dblink at the same time.
I've recently been getting at least one email a week, off-list, from someone
interested in using dblink against *other* RDBMSs (e.g. Oracle, Sybase, etc).
Here's what I'm thinking about doing (in very loose terms -- comments,
pointers, etc very much welcome):
- split dblink into a set of front-end user accessible functions (e.g. dblink,
dblink_exec, etc) and a loadable library of libpq based functions (a
"connection library") that implement the front-end ones. The plpq functions
would be part of the libpq connection library, with more generic front-end
user functions.
- use the libpq connection library as the model api for other types of
connection libraries (JDBC, ODBC, oracle, freetds <sybase, mssql>, mysql, etc).
- create an in-memory hash table of loaded connection libraries, and perhaps a
table for registering the library paths, etc.
- create an in memory hash table of persistent connections, and perhaps a
table to register connections for reuse.
As I said, this is all very preliminary; comments, suggestions, requests are
all welcome. I'm not quite sure how to do the loadable library part, but I
envision it being similar to how PLs are loaded when needed, and used when
already loaded.
Joe
From | Date | Subject | |
---|---|---|---|
Next Message | Nicolai Tufar | 2002-11-30 21:18:34 | Re: Locale-dependent case conversion in {identifier} |
Previous Message | Greg Sabino Mullane | 2002-11-30 21:10:39 | GnuPG / PGP signed MD5 checksums for PostgreSQL 7.3 |
From | Date | Subject | |
---|---|---|---|
Next Message | Nicolai Tufar | 2002-11-30 21:18:34 | Re: Locale-dependent case conversion in {identifier} |
Previous Message | Christopher Kings-Lynne | 2002-11-30 21:01:39 | Re: Boolean casting in 7.3 -> changed? |