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
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 |