Re: delta relations in AFTER triggers - Mailing list pgsql-hackers

From Marti Raudsepp
Subject Re: delta relations in AFTER triggers
Date
Msg-id CABRT9RBddGWGYpRZDeO9j_aDGiMAJowiVApXrdoPxOCCt5OhoA@mail.gmail.com
Whole thread Raw
In response to Re: delta relations in AFTER triggers  (Kevin Grittner <kgrittn@ymail.com>)
List pgsql-hackers
On Thu, Aug 28, 2014 at 12:03 AM, Kevin Grittner <kgrittn@ymail.com> wrote:
>> In essence, make the relations work like PL/pgSQL
>> variables do. If you squint a little, the new/old relation is a variable
>> from the function's point of view, and a parameter from the
>> planner/executor's point of view. It's just a variable/parameter that
>> holds a set of tuples, instead of a single Datum.

> will be surprised if someone doesn't latch onto this to create a
> new "declared temporary table" that only exists within the scope of
> a compound statement (i.e., a BEGIN/END block).  You would DECLARE
> them just like you would a scalar variable in a PL, and they would
> have the same scope.
>
> I'll take a look at doing this in the next couple days, and see
> whether doing it that way is as easy as it seems on the face of it.

We already have all this with refcursor variables. Admittedly cursors
have some weird semantics (mutable position) and currently they're
cumbersome to combine into queries, but would a new "relation
variable" be sufficiently better to warrant a new type?

Why not extend refcursors and make them easier to use instead?

Regards,
Marti



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: replication commands and log_statements
Next
From: rohtodeveloper
Date:
Subject: Why data of timestamptz does not store value of timezone passed to it?