At 10:12 PM 12/2/99 -0500, you wrote:
>Date: Thu, 02 Dec 1999 12:59:31 -0500
>From: Tom Lane <tgl@sss.pgh.pa.us>
>Subject: Re: [INTERFACES] Data Migration
>
>"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?
It's been a while since I've done it, but IIRC Informix syntax is
table.column@database, where database is basically an entry in a file
listing host, server & protocol, all of which you could specify one way or
another (I use Java/JDBC these days).
As for why more than one database, the answer to that is - some of us run
very large databases and are seriously looking at parallelising them in
segments across multiple different machines on the network. Currently, I
don't need back end support for this stuff - I'm using RMI instead and can
run queries on any JDBC compliant database on any machine I can see, in
their own thread. But I can see the uses for it in the engine; for example
I can't yet do a join across the databases directly in SQL. I used to be
able to do this (in theory) in Informix.
Peter Wiley
