Re: [GENERAL] One SQL to access two databases.
От | Joe Conway |
---|---|
Тема | Re: [GENERAL] One SQL to access two databases. |
Дата | |
Msg-id | 3DE92978.20604@joeconway.com обсуждение исходный текст |
Ответ на | Re: [GENERAL] One SQL to access two databases. (Darko Prenosil <darko.prenosil@finteh.hr>) |
Ответы |
Re: [GENERAL] One SQL to access two databases.
|
Список | 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 по дате отправления: