From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Nicolas Thauvin <nicolas(dot)thauvin(at)dalibo(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Foreign tables privileges not shown in information_schema.table_privileges |
Date: | 2017-08-14 20:00:44 |
Message-ID: | 9136.1502740844@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> - Materialized views not included. I think that is an intentional
> omission. It's valid to reconsider, but it would be to be a separate
> discussion.
Yes. The problem is that matviews are not in the SQL standard, so
what are you going to show in tables.table_type? Do they even belong
there, rather than under "views"?
Our approach to date has been that objects that are outside the scope of
what can be shown standards-compliantly should just be omitted from the
information_schema views. Thus for example exclusion constraints are
omitted. They're certainly a type of constraint, but we can't wedge them
into the information_schema view of things without having not-per-spec
output of some sort. I think the same policy must apply to matviews.
It's not entirely clear to me that it was a good idea for 262e821d
to expose partitioned tables in information_schema. By doing that,
you're essentially arguing that there is no reason for an application
to know the difference between a plain table and a partitioned one.
Maybe that's true, but it's not incontrovertible.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-08-14 20:13:33 | Re: Crash report for some ICU-52 (debian8) COLLATE and work_mem values |
Previous Message | Peter Geoghegan | 2017-08-14 19:54:20 | Re: Crash report for some ICU-52 (debian8) COLLATE and work_mem values |