Re: and it's not a bunny rabbit, either

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: David Fetter <david(at)fetter(dot)org>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: and it's not a bunny rabbit, either
Date: 2010-12-31 05:07:18
Message-ID: AANLkTi=6paE_75zeuCauOdMKxYKOVSv5uzaaT-Yt7Me=@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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
>> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-12-31 05:27:54 Re: Problems with autovacuum and vacuum
Previous Message Robert Haas 2010-12-31 05:02:13 Re: Sync Rep Design