Re: [INTERFACES] Data Migration - Mailing list pgsql-interfaces

From Tom Lane
Subject Re: [INTERFACES] Data Migration
Date
Msg-id 28473.944157571@sss.pgh.pa.us
Whole thread Raw
In response to Re: [INTERFACES] Data Migration  ("Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>)
List pgsql-interfaces
"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

************




pgsql-interfaces by date:

Previous
From: Oleg Bartunov
Date:
Subject: Re: [INTERFACES] Slow join query optimisation?
Next
From: Mark Dalphin
Date:
Subject: Re: [INTERFACES] Data Migration