Re: delta relations in AFTER triggers

Поиск
Список
Период
Сортировка
От Marti Raudsepp
Тема Re: delta relations in AFTER triggers
Дата
Msg-id CABRT9RBddGWGYpRZDeO9j_aDGiMAJowiVApXrdoPxOCCt5OhoA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: delta relations in AFTER triggers  (Kevin Grittner <kgrittn@ymail.com>)
Список 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 по дате отправления:

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: replication commands and log_statements
Следующее
От: rohtodeveloper
Дата:
Сообщение: Why data of timestamptz does not store value of timezone passed to it?