Skip site navigation (1) Skip section navigation (2)

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: (view raw or whole 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
The Enterprise PostgreSQL Company

In response to


pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group