Re: [GENERAL] One SQL to access two databases. - Mailing list pgsql-hackers

From Joe Conway
Subject Re: [GENERAL] One SQL to access two databases.
Date
Msg-id 3DE92978.20604@joeconway.com
Whole thread Raw
In response to Re: [GENERAL] One SQL to access two databases.  (Darko Prenosil <darko.prenosil@finteh.hr>)
Responses Re: [GENERAL] One SQL to access two databases.  (Karel Zak <zakkr@zf.jcu.cz>)
List 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



pgsql-hackers by date:

Previous
From: "Christopher Kings-Lynne"
Date:
Subject: Re: Boolean casting in 7.3 -> changed?
Next
From: "Nicolai Tufar"
Date:
Subject: Re: Locale-dependent case conversion in {identifier}