From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Ross J(dot) Reedstrom" <reedstrm(at)wallace(dot)ece(dot)rice(dot)edu> |
Cc: | pgsql-interfaces(at)postgresql(dot)org |
Subject: | Re: [INTERFACES] Data Migration |
Date: | 1999-12-02 17:59:31 |
Message-ID: | 28473.944157571@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-interfaces |
"Ross J. Reedstrom" <reedstrm(at)wallace(dot)ece(dot)rice(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Dalphin | 1999-12-02 18:03:14 | Re: [INTERFACES] Data Migration |
Previous Message | Oleg Bartunov | 1999-12-02 16:45:48 | Re: [INTERFACES] Slow join query optimisation? |