Re: LIKE INCLUDING COMMENTS code is a flight of fancy

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Tom Lane wrote:
>> I'm for forbidding comments on index columns. The amount of work
>> required to support the feature fully seems far out of proportion to
>> its value.
>>
>> In any case, if pg_dump drops such comments (which I had forgotten,
>> but it seems true after a quick look at the code), then we could
>> certainly get away with having LIKE not copy them. That would fix
>> the immediate problem.

> If we're going to keep the comments we should dump them. I don't mind
> dropping them altogether - it's hardly a killer feature. We should just
> be consistent, IMNSHO.

Well, let's just forbid them then. It'll take just a few extra lines in
comment.c to throw an error if the target table has the wrong relkind.
Then we can pull out the troublesome code in parse_utilcmds.c.

It strikes me also that this changes the terms of discussion for the
other patch I was working on. I was mistakenly assuming that we could
not change the naming convention for individual index columns because
it would cause errors during dump/reload of per-column comments. But
since pg_dump never has supported that, there is no such risk. I
propose re-instating my previous idea of replacing "pg_expression_n"
with the name chosen by FigureColname. This not only makes the index
column names a bit more useful, but it fixes the disadvantage I was
on about for CREATE TABLE LIKE: it can get the FigureColname name
from the index's pg_attribute entry, so there's no problem with
producing smart index-expression column names when cloning indexes.

regards, tom lane