From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Shigeru HANADA <hanada(at)metrosystems(dot)co(dot)jp>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SQL/MED - core functionality |
Date: | 2010-12-14 15:57:46 |
Message-ID: | AANLkTimsaFszZMGyz6tx_84MeCaMgn6dTa7GL+9VHzBG@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Dec 14, 2010 at 10:48 AM, Itagaki Takahiro
<itagaki(dot)takahiro(at)gmail(dot)com> wrote:
> On Tue, Dec 14, 2010 at 23:45, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> We need RULEs or INSTEAD OF TRIGGERs to support updatable foreign tables.
>>
>> We do? Why can't the support for updating foreign tables be built-in
>> rather than trigger-based?
>
> Do we have any concrete idea for the built-in update feature?
> There are no definitions in the SQL standard about interface for updates.
>
> So, I think RULE and TRIGGER are the best solution for now.
> In addition, even if we support some kinds of built-in update feature,
> I still think RULE and TRIGGER are useful, for example, logging purpose.
I think triggers are useful. I see no reason to support rules. If
the first version of our SQL/MED functionality is read-only, that's
fine. But triggers are slow, clumsy, and expose implementation
details to users, so those should be something that we provide as a
way of making the database extensible, not something we use to build
core functionality.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Chris Browne | 2010-12-14 16:24:44 | Re: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED |
Previous Message | David Fetter | 2010-12-14 15:51:36 | Re: SQL/MED - core functionality |