| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, 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 14:59:33 |
| Message-ID: | 26252.1292338773@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Dec 14, 2010 at 9:42 AM, Itagaki Takahiro
> <itagaki(dot)takahiro(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?
It *has* to be built in. What exactly would you imagine a rule or
trigger is going to do? It won't have any below-SQL-level access to the
foreign table with which it could issue some magic command that's not
spelled UPDATE; and even if it did, why wouldn't you just spell that
command UPDATE?
There would be value in being able to fire triggers on foreign-table
updates just like you can on local tables. It might well be that that
would just fall out of the implementation, since triggers are handled at
the top level of the executor, which shouldn't need to know the
difference. But if it doesn't fall out easily, I don't mind postponing
that feature till later.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Merlin Moncure | 2010-12-14 15:06:31 | Re: Transaction-scope advisory locks |
| Previous Message | Andrew Dunstan | 2010-12-14 14:59:03 | Re: Transaction-scope advisory locks |