From: | Alban Hertroys <haramrae(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: SQL functions and triggers? |
Date: | 2014-11-25 23:35:52 |
Message-ID: | 678FDA29-2F1D-4AC4-8499-B5599957B44B@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> On 25 Nov 2014, at 22:24, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Alban Hertroys <haramrae(at)gmail(dot)com> writes:
>> In the past, when writing trigger functions, I’ve always used pl/pgsql without giving it a second thought. Today I was modifying a database creation script that was originally intended for Firebird to work with Postgres and the example trigger procedures in there were very close to pure SQL.
>
>> Hence, I started rewriting them as SQL functions, but is that really
>> possible?
>
> No, nobody's ever tried to make that work. It could probably be done
> with sufficiently many round tuits, but it's not clear that there's
> any benefit that would justify the work. Surely dropping some SQL
> commands into plpgsql isn't very hard …
It isn’t. I was just wondering whether I was missing something obvious to make an SQL function return a trigger type value. I didn’t think there was, but it never hurts to ask ;)
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll find there is no forest.
From | Date | Subject | |
---|---|---|---|
Next Message | Sanjaya Vithanagama | 2014-11-25 23:41:56 | Re: Avoiding deadlocks when performing bulk update and delete operations |
Previous Message | Dave Potts | 2014-11-25 22:56:14 | Re: returning only part of a rule set |