From: | Susan Hurst <susan(dot)hurst(at)brookhurstdata(dot)com> |
---|---|
To: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Displaying Comments in Views |
Date: | 2019-01-28 15:49:52 |
Message-ID: | 8c21bf3727cd98b3e80f1253b78e3ce2@mail.brookhurstdata.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Thx for the great info. I appreciate your pointing me in the right
direction.
Sue
---
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Susan E Hurst
Principal Consultant
Brookhurst Data LLC
Email: susan(dot)hurst(at)brookhurstdata(dot)com
Mobile: 314-486-3261
On 2019-01-28 09:27, Tom Lane wrote:
> Susan Hurst <susan(dot)hurst(at)brookhurstdata(dot)com> writes:
>> What is the trick for displaying column comments in views?
>> The query below works as expected when the table_schema includes
>> tables,
>> however it shows nothing when the table_schema contains only views.
>
> No surprise, since you're using pg_statio_all_tables as the source of
> tables, and that contains, well, only tables.
>
> I'm not quite sure why you'd choose that view anyway. Personally I'd
> have gone directly to pg_class, and then probably filtered on relkind
> if there were things I didn't want to see. Or you could use
> information_schema.tables.
>
> Also, I'm too lazy to check on how information_schema.columns defines
> "ordinal_position", but I wonder if it tries to leave out dropped
> columns, or might do so in future. That puts this join condition
> at risk: "pd.objsubid = c.ordinal_position".
>
> You'd likely be better off to join pg_class and pg_attribute to
> pg_description, rather than working with proxies for them.
>
> https://www.postgresql.org/docs/current/catalogs.html
>
> regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2019-01-28 15:55:33 | Re: number and type of locks for an alter sequence |
Previous Message | Adrian Klaver | 2019-01-28 15:47:49 | Re: Displaying Comments in Views |