Re: Prelim specs for parser hooks for plpgsql

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Prelim specs for parser hooks for plpgsql
Date: 2009-10-22 02:19:14
Message-ID: 162867790910211919v2dc44a20kb8eb5371283d5b0@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2009/10/22 Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>:
>
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>> 3. The pre-transform hook would have a signature like
>>       Node *hook(ParseState *pstate, ColumnRef *cref)
>>
>> 4. The post-transform hook would have a signature like
>>       Node *hook(ParseState *pstate, ColumnRef *cref, Node *var)
>
> Are there any relationships between the hooks and
> Function Call Hook/parser hook submitted by Pavel-san?
> https://commitfest.postgresql.org/action/patch_view?id=160

No, "my" hook was little bit more general and global. And I was to
able inject running environment.

>
> If we can also use them in normal SQL parsing, they are very useful
> to implement SYSDATE global variable for porting from Oracle.
>

I thing, so you need a global hook, and it isn't what Tom propose. But
Tom's proposal is correct - we don't need plpgsql behave ouside
plpgsql. Simply, if you like add some special variables like SYSDATE
or others, then you need some add new global hook.

Pavel

Regards
Pavel Stehule

> Regards,
> ---
> ITAGAKI Takahiro
> NTT Open Source Software Center
>
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Itagaki Takahiro 2009-10-22 02:33:10 TRIGGER with WHEN clause
Previous Message Pavel Stehule 2009-10-22 02:06:11 Re: Controlling changes in plpgsql variable resolution