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-30 19:34:45
Message-ID: AANLkTik8Oyko1ZheYc2XmVdOFoFiHoGL95_8HCXugdRv@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Thu, Dec 30, 2010 at 12:32 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Thu, Dec 30, 2010 at 11:49 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> One possibility is to break it down like this:
>>
>>        ERROR: foo is a sequence
>>        DETAIL: Triggers can only be used on tables and views.
>>
>> This could still be emitted by a function such as you suggest, and
>> indeed that would be the most practical way from both a consistency
>> and code-size standpoint.
>
> Great idea.  I should have thought of that.

On further reflection, this can still turn into a laundry list in certain cases.

DETAIL: You can only comment on columns of tables, views, and composite types.

seems less helpful than:

DETAIL: Comments on relations with system-generated column names are
not supported.

I think that for rules, triggers, constraints, and anything that only
works on a single relkind, we can't do much better than to list the
specific object types.  But where there's some sort of guiding
principle involved I think we'd do well to articulate it.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

pgsql-hackers by date

Next:From: Tomas VondraDate: 2010-12-30 19:38:03
Subject: Re: estimating # of distinct values
Previous:From: Chris BrowneDate: 2010-12-30 19:27:07
Subject: Re: C++ keywords in headers

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