pgsql: Include foreign tables in information_schema.table_privileges
Include foreign tables in information_schema.table_privileges
This appears to have been an omission in the original commit
0d692a0dc9f. All related information_schema views already include
foreign tables.
Reported-by: Nicolas Thauvin <nicolas.thauvin@dalibo.com>
Branch
------
REL9_3_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/9f0f4efc2f1ebbf37c1d52cb8c983d5dad65dcd6
Modified Files
--------------
src/backend/catalog/information_schema.sql | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
On Tue, Aug 15, 2017 at 7:41 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
Include foreign tables in information_schema.table_privileges
This appears to have been an omission in the original commit
0d692a0dc9f. All related information_schema views already include
foreign tables.Reported-by: Nicolas Thauvin <nicolas.thauvin@dalibo.com>
I would have been disinclined to back-patch this. Somebody could be
depending on the current behavior, and now we'll end up with two kinds
of clusters, one where initdb was done before these changes and
another where it was done afterward. So nobody will be able to count
on this behavior one way or the other.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 8/16/17 07:27, Robert Haas wrote:
On Tue, Aug 15, 2017 at 7:41 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
Include foreign tables in information_schema.table_privileges
This appears to have been an omission in the original commit
0d692a0dc9f. All related information_schema views already include
foreign tables.Reported-by: Nicolas Thauvin <nicolas.thauvin@dalibo.com>
I would have been disinclined to back-patch this. Somebody could be
depending on the current behavior, and now we'll end up with two kinds
of clusters, one where initdb was done before these changes and
another where it was done afterward. So nobody will be able to count
on this behavior one way or the other.
I understand that. But this is an additive change, so to speak, so
whatever behavior someone was relying on should continue to work.
I did not backpatch 9b5140fb503eb50634cd7e080d41f4d9af41e0a6 because
that is a behavior-breaking change.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers