Queries across multiple databases =?iso-8859-1?q?=A0?=(was: SELECT from a table in another database).

From: Andrew Rawnsley <ronz(at)ravensfield(dot)com>
To: pgsql-hackers(at)postgresql(dot)org, pgsql-general(at)postgresql(dot)org
Subject: Queries across multiple databases =?iso-8859-1?q?=A0?=(was: SELECT from a table in another database).
Date: 2001-05-21 11:55:13
Message-ID: 01052107551300.23753@coho.ravensfield.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers


>> I don't know what you are using those database for, but nothing prevents
> >you from letting your clients connect to the different databases the
> >same time.

>But that requires me to make a new database connection for each database I
>need to access.

>And putting 200+ tables in one single database is not an option.

>The application which needs to be able to do this is a
>cross-database-application (MSSQL, Oracle, Sybase) and I have almost no
>room for doing major changes to the SQL which this application uses.

>But the lack of this feature in Postgres makes it almost impossible to
>make a structured database design for huge application. I know this
>question have been asked before in another postgres forum as early as
>1998, and what Bruce Momjian said then was that most commercial databases
>couldn't do it, which was probably right for 1998, but today even MySQL
>can do this! Sybase, Oracle and MSSQL can also do this. I think even DB2
>and Informix can.

>I was really suprised when I discovered that this was even an issue with
>Postgres, because everything else in this wonderful DBM is on an
>enterprise level of quality and functionality.

I'm stuck in the same cleft in the tree - database application originally
written for Oracle and Sybase, that still needs to work in Oracle, and the
SQL and database structure etched in stone. The problem isn't about a client
with multiple connections, its about executing the following query:

SELECT A.*, B.* FROM FOO.USERS A, BAR.FAVORITE_BEERS B WHERE A.USER =
B.GUZZLER

Putting 200+ tables in a database certainly isn't a big deal, as I think Tom
Lane points out in another post in this thread. I am poking at the parser in
my copious free time just to see how easy it would be to just strip a schema
name off the items in the FROM clause before anything happens, but one
doesn't pick up the internals of the parser in 10-15 minutes a day...hints
anyone? Anyway, this way I COULD put all the tables in one database, keep the
schema-based queries, and no one would ever know.

I would twitch on the floor in utter extasy if I could hose Oracle...while
their licensing is more flexible than in the past, it still doesn't sit
right, and despite all their claims to the contrary their java support is a
joke. And maybe their pinheaded sales reps WOULD STOP CALLING ME EVERY WEEK.

If I ever come up with said schema-dropping patch, and anyone else wants it,
let me know.

--
Regards,

Andrew Rawnsley
Ravensfield Geographic Resources, Ltd.
(740) 587-0114
www.ravensfield.com

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Flacco 2001-05-21 12:59:28 pgaccess - no "numeric" data type?
Previous Message Iwan van der Kleyn 2001-05-21 11:50:45 initdb doesn't work with cygwin 1.3.1?

Browse pgsql-hackers by date

  From Date Subject
Next Message Henshall, Stuart - WCP 2001-05-21 12:00:59 RE: Plans for solving the VACUUM problem
Previous Message Arsalan Zaidi 2001-05-21 11:46:31 Using 7.1rc1 under RH 6.2