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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2010-12-30 19:38:03 | Re: estimating # of distinct values |
Previous Message | Chris Browne | 2010-12-30 19:27:07 | Re: C++ keywords in headers |