* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > Having COMMENT ON accept a general query whose result is then cast to
> > text and stored as the comment would allow this to be done, eg:
>
> > COMMENT ON table IS (pg_get_comment('table') || ' new text');
>
> Putting general subexpressions into utility statements has some
> implementation issues. Plus, it's not really all that powerful.
> 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 ...
>
> The main thing lacking to make that into a real proposal would be
> a way of naming the object the comment is for; but I think Alvaro's
> already exposed something corresponding to ObjectAddress to SQL, no?
Yes and yes. I like the 'pg_set_comment' idea, and I think we do have
something or other now through ObjectAddress and friends.
> > We could also have new syntax along these lines, for this specific case:
> > COMMENT ON table ADD ' new text';
>
> Wouldn't have a big problem with that, as it'd address a common case
> for not much work.
We could have this also, I suppose.
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. Not sure how much
we want to try and go down that road, or if we are happy to tell people
to just use:
select pg_set_comment('table','q',pg_get_comment('table','q') || 'E\n' || now() || ': new comment'));
Not sure why anyone would grouse about that though ...
Thanks!
Stephen
