Re: SHOW TABLES

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Boszormenyi Zoltan <zb(at)cybertec(dot)at>
Cc: Guillaume Lelarge <guillaume(at)lelarge(dot)info>, jd(at)commandprompt(dot)com, Simon Riggs <simon(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: SHOW TABLES
Date: 2010-09-21 11:55:27
Message-ID: AANLkTi=VqnmFTg=RNOF5ryoAtn-OMes9Y0UK48AnekR7@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Sep 21, 2010 at 4:52 AM, Boszormenyi Zoltan <zb(at)cybertec(dot)at> wrote:
> I think it's related to making this work:
>    SELECT * FROM db.schema.table;

Which is a non-starter, I think. Every function in the system that
thinks an OID uniquely identifies a database object would need to
modified, or else you'd need unique indices that can span tables in
multiple different databases. It would also require blowing a massive
hole in the isolation wall between databases, and reengineering of
every place that thinks a backend can be connected to only one
database at a time. None of which would be good for either code
stability or performance.

The only way I can imagine making this work is if any references of
that type got treated like foreign tables: spawn a "helper backend"
connected to the correct DB (failing if you haven't permissions), and
then stream the tuples back to the main backend from there.
Considering the amount of effort that would be required for the amount
of benefit you'd actually derive from it, I doubt anyone is likely to
tackle this any time soon...

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2010-09-21 12:12:33 Re: .gitignore files, take two
Previous Message Robert Haas 2010-09-21 11:12:06 Re: .gitignore files, take two