Thread: One more question regarding dblink
Hi, I know I should have clubbed in last post but did not notice. 1. Why is that dblink allows only one persistent connection? It should allow more than one persistent connections to same or different databases, searchable by name. Of course we do not expect number of remote connection to be huge. So a simple structure would suffice. 2. To create a persistent connection, one has to call dblink_connect explicitly. Oracle allows a database link connection to be part of database schema. Hence when a database comes up it brings the database link up as well. Is there an equivalent of .profile/.logout per database/per schema/per table in postgresql? That should be an ideal place to put a database link initiation/termination. Should be a nifty addtion. I don't know how practical that sounds to core developers. Shridhar
Shridhar Daithankar wrote: > 1. Why is that dblink allows only one persistent connection? It should allow > more than one persistent connections to same or different databases, > searchable by name. Of course we do not expect number of remote connection to > be huge. So a simple structure would suffice. Great idea, and I wanted to do that eventually (again, possibly for 7.4), but I didn't have the time last year when I updated dblink for 7.3. And again, patches gratefully accepted. > 2. To create a persistent connection, one has to call dblink_connect > explicitly. Oracle allows a database link connection to be part of database > schema. Hence when a database comes up it brings the database link up as > well. > > Is there an equivalent of .profile/.logout per database/per schema/per table > in postgresql? That should be an ideal place to put a database link > initiation/termination. As Tom has mentioned within the last day or two, the right answer is not to emulate Oracle, but instead to implement external data access per the SQL-MED spec. That has been discussed at some length in the past -- search the archives. As it is not a small undertaking, and I had other higher personal priorities during this release cycle, it will not happen for 7.4. Perhaps I'll take it on for 7.5 (but then again, perhaps not). Joe
Joe Conway wrote: > As Tom has mentioned within the last day or two, the right answer is not > to emulate Oracle, but instead to implement external data access per the > SQL-MED spec. That has been discussed at some length in the past -- > search the archives. If it's been discussed at length in the past, I'm unable to find it in the archives. The oldest article with the text "sql-med" (or "SQL-MED") that shows up was written yesterday! -- Kevin Brown kevin@sysexperts.com
Kevin Brown wrote: > Joe Conway wrote: > >>As Tom has mentioned within the last day or two, the right answer is not >>to emulate Oracle, but instead to implement external data access per the >>SQL-MED spec. That has been discussed at some length in the past -- >>search the archives. > > If it's been discussed at length in the past, I'm unable to find it in > the archives. The oldest article with the text "sql-med" (or > "SQL-MED") that shows up was written yesterday! > Looks like it is actually "SQL/MED", not "SQL-MED" -- sorry if I misdirected you. http://archives.postgresql.org/pgsql-hackers/2002-12/msg00407.php Joe
Joe Conway wrote: > http://archives.postgresql.org/pgsql-hackers/2002-12/msg00407.php Thanks! The spec is only 500 pages long. How hard can it be to implement? :-) -- Kevin Brown kevin@sysexperts.com
On 16 Apr 2003 at 9:19, Joe Conway wrote: > Shridhar Daithankar wrote: > > Is there an equivalent of .profile/.logout per database/per schema/per table > > in postgresql? That should be an ideal place to put a database link > > initiation/termination. > > As Tom has mentioned within the last day or two, the right answer is not > to emulate Oracle, but instead to implement external data access per the > SQL-MED spec. That has been discussed at some length in the past -- > search the archives. As it is not a small undertaking, and I had other > higher personal priorities during this release cycle, it will not happen > for 7.4. Perhaps I'll take it on for 7.5 (but then again, perhaps not). I agree that standards should be done. But if it is question of providing transparent remote database objects with SQL-MED not even being on drawing board, I would not mind a postgresql way of doing it. Something is better than nothing. ByeShridhar -- Marriage, n.: The evil aye.