On Thu, Dec 30, 2010 at 9:30 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> I think this thread has worked itself around to where it's entirely
> 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.
The Enterprise PostgreSQL Company
In response to
pgsql-hackers by date
|Next:||From: Robert Haas||Date: 2010-12-31 05:27:54|
|Subject: Re: Problems with autovacuum and vacuum|
|Previous:||From: Robert Haas||Date: 2010-12-31 05:02:13|
|Subject: Re: Sync Rep Design|