Re: and it's not a bunny rabbit, either - Mailing list pgsql-hackers

From Robert Haas
Subject Re: and it's not a bunny rabbit, either
Date
Msg-id AANLkTi=1GVjc2K+n+-etGa=LxXZAE2QtAq_Cw=Ujz4_Y@mail.gmail.com
Whole thread Raw
In response to Re: and it's not a bunny rabbit, either  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: and it's not a bunny rabbit, either  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
On Thu, Dec 30, 2010 at 11:00 AM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> Excerpts from Robert Haas's message of jue dic 30 12:47:42 -0300 2010:
>
>> After further thought, I think it makes sense to change this around a
>> bit and create a family of functions that can be invoked like this:
>>
>> void check_relation_for_FEATURE_support(Relation rel);
>>
>> ...where FEATURE is constraint, trigger, rule, index, etc.  The
>> function will be defined to throw an error if the relation isn't of a
>> type that can support the named feature.  The error message will be of
>> the form:
>>
>> constraints can only be used on tables
>> triggers can be used only on tables and views
>> etc.
>
> So this will create a combinatorial explosion of strings to translate?
> I liked the other idea because the number of translatable strings was
> kept within reasonable bounds.

No, quite the opposite.  With the other approach, you needed:

constraints cannot be used on views
constraints cannot be used on composite types
constraints cannot be used on TOAST tables
constraints cannot be used on indexes
constraints cannot be used on foreign tables

With this, you just need:

constraints can only be used on tables

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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Old git repo
Next
From: Robert Haas
Date:
Subject: Re: Old git repo