Received: from strait.hba.marine.csiro.au (strait.hba.marine.csiro.au [140.79.17.2]) by hub.org (8.9.3/8.9.3) with ESMTP id AAA98786 for ; Fri, 3 Dec 1999 00:59:24 -0500 (EST) (envelope-from Peter.Wiley@marine.csiro.au) Received: from ssrvnt2-hf (ssrvnt2-hf [140.79.21.116]) by strait.hba.marine.csiro.au (8.9.3/8.9.3) with ESMTP id QAA14608 for ; Fri, 3 Dec 1999 16:59:17 +1100 (EDT) Message-Id: <4.2.0.58.19991203170117.00a9f940@mailhost.ml.csiro.au> X-Sender: wil820@mailhost.ml.csiro.au X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 03 Dec 1999 17:06:33 +1100 To: pgsql-interfaces@hub.org From: Peter Wiley Subject: Re: pgsql-interfaces-digest V1 #570 In-Reply-To: <199912030312.WAA38773@hub.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 10:12 PM 12/2/99 -0500, you wrote: >Date: Thu, 02 Dec 1999 12:59:31 -0500 >From: Tom Lane >Subject: Re: [INTERFACES] Data Migration > >"Ross J. Reedstrom" 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