Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
	by hub.org (8.9.3/8.9.3) with ESMTP id NAA71257
	for <pgsql-interfaces@postgresql.org>;
	Thu, 2 Dec 1999 13:00:05 -0500 (EST)
	(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id MAA28475;
	Thu, 2 Dec 1999 12:59:31 -0500 (EST)
To: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
cc: pgsql-interfaces@postgresql.org
Subject: Re: [INTERFACES] Data Migration 
In-reply-to: Your message of Thu, 2 Dec 1999 09:45:21 -0600
	<19991202094521.A11044@wallace.ece.rice.edu>
Date: Thu, 02 Dec 1999 12:59:31 -0500
Message-ID: <28473.944157571@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu> writes:
> This notation, db.table.field, does seem to be how other DBMSs do
> it. I've been wondering, however, if our parser would have any trouble
> with it, since in an identifier string token1.token2, token1 is no longer
> guaranteed to be a table.

The parser would indeed get confused, since multiple dots is an old and
still-supported PostQUEL notation for some sort of function invocation
(can't say that I fully understand it).  I suppose we could rip that out
without drawing too many complaints.  However, parser problems would be
the least of the worries in supporting multiple-database access within a
single backend.  We're talking about a major project here, and I'm not
seeing value in it proportional to the work required.  If you don't want
to have multiple backend connections open in a client, why not refactor
your database layout so that all the stuff you need is in one database?

			regards, tom lane