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.
Bye
Shridhar
--
Marriage, n.: The evil aye.