From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: RFC: ALTER SYSTEM [...] COMMENT |
Date: | 2017-04-26 19:07:11 |
Message-ID: | 28763.1493233631@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>> It'd be better to invent inverse pg_get_comment and pg_set_comment
>> functions, then you could do bulk-update things like
>> select pg_set_comment('table', pg_get_comment('table') || ' more')
>> from pg_class where ...
> Of course, once we start thinking about what kind of comments people
> might be interested in, as alluded to elsewhere, it's entirely likely
> they'll want to get things like timestamps included and other
> information that, ultimately, would be better if it was structured and
> not just thrown together into a free-form text field.
It's not hard to imagine people deciding that all their comments will
be (the text form of) JSON objects containing certain fields. But
I don't think it's appropriate for us to mandate that sort of thing.
Given get/set comment functions as above, users could write wrapper
functions implementing their local conventions.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Konstantin Knizhnik | 2017-04-26 19:35:21 | Re: Cached plans and statement generalization |
Previous Message | Peter Eisentraut | 2017-04-26 18:41:19 | Re: Fixup some misusage of appendStringInfo and friends |