On Thu, Dec 30, 2010 at 9:30 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> I think this thread has worked itself around to where it's entirely >> pointless. > > I understand your frustration, but it's not clear to me that there *is* > any simple solution to this problem. Fundamentally, adding new relkinds > to the system is always going to require running around and looking at a > lot of code to see what's affected; and that goes for the error messages > too. I put no stock at all in the idea that writing a "guiding > principle" in the error messages will avoid anything, because as often > as not, adding a fundamentally new relkind is going to involve some > tweaking of what those principles are.
I think that's true in some cases but not all. The system-generated attribute names thing actually applies in several cases, and I think it's pretty cut-and-dried. When you get into something like which kinds of relations support triggers, that's a lot more arbitrary. >> ... This message also does nothing to help the user understand WHY we don't >> allow renaming the attributes of his sequence or TOAST table, whereas >> the proposed revision does. > > I remain unconvinced that the average user cares, or will be able to > extrapolate the message to understand what's supported or not, even > if he does care about the reason for the restriction. I'm convinced, but that only makes one of us. I think for now what I had better do is try to get this SQL/MED patch finished up by soldiering through this mess rather than trying to fix it. I think it's going to be kind of ugly, but we haven't got another plan then we're just going to have to live with the ugliness. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers