From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: TODO list (was Re: Contributing with code) |
Date: | 2017-12-31 18:51:13 |
Message-ID: | 20171231185113.GQ2416@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom, Robert, all,
* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > Also, let's delete the TODO list. People keep using it as a source of
> > project ideas, and that's bad.
>
> If we're not going to maintain/curate it properly, I agree it's not
> worth keeping it around. But I'd rather see somebody put some effort
> into it ...
I don't see anything particularly wrong with the specific item chosen
off of the todo list- it'd be nice to be able to tell what objects exist
in a tablespace even if they're in other databases.
The todo entry even talks about why it's difficult to do and what the
expected way to go about doing it is (that is, connect to each database
that has objects in the tablespace and query it to find out what's in
the tablespace). Craig's suggestion is an interesting alternative way
though and I'm not sure that it'd be all that bad, but it would be
limited to catalog tables.
If we'd extend the system to allow transparent usage of postgres_fdw to
access other databases which are part of the same cluster, then this
could end up being much simpler (eg: select * from
otherdatabase.pg_catalog.pg_class ...).
Thanks!
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2017-12-31 19:02:49 | Re: TODO list (was Re: Contributing with code) |
Previous Message | Tom Lane | 2017-12-31 18:42:32 | TODO list (was Re: Contributing with code) |