Re: RFC: ALTER SYSTEM [...] COMMENT

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

In response to

Browse pgsql-hackers by date

  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