| From: | Jim Nasby <jim(at)nasby(dot)net> |
|---|---|
| To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Steve Singer <steve(at)ssinger(dot)info>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: plpgsql_check_function - rebase for 9.3 |
| Date: | 2013-12-09 18:51:01 |
| Message-ID: | 52A61115.6040305@nasby.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 12/8/13 11:24 PM, Pavel Stehule wrote:
> > #option check_on_first_start
> > #option check_on_create
> > #option check_newer
>
> what exactly check_newer means, does it mean whenever a function is
> replaced (changed)?
>
>
> no, it means, so request for check will be ignored ever - some functions cannot be deeply checked due using dynamic SQL or dynamic created data types - temporary tables created in functions.
So presumably it would be check_never, not check_newer... :) BTW, it's not terribly hard to work around the temp table issue; you just need to create the expected table in the session when you create the function. But even in this case, I think it would still be good to check what we can, like at least basic plpgsql syntax.
Do we really need first_start? ISTM that if you're dependent on run state then you're basically out of luck.
--
Jim C. Nasby, Data Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Stark | 2013-12-09 18:54:21 | Re: ANALYZE sampling is too good |
| Previous Message | Robert Haas | 2013-12-09 18:50:26 | Re: Extra functionality to createuser |