2013/12/9 Jim Nasby <j...@nasby.net> > 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. >
I sorry. You cannot to create temporary table - this check should not have any side effect - and creating temporary table can run some event trigger. But there should be some hints for check like annotations or some similar. Or you can minimize a area where check will be disabled. > > Do we really need first_start? ISTM that if you're dependent on run state > then you're basically out of luck. > I afraid so checking on creation time is not enough for plpgsql. and I have a very good experience with check on start from plpgsql_lint usage when I wrote a regression tests. A "first start" doesn't create dependency on state - but just more preciously define a time, when checking will be done. Probably a option check_create_and_start can be useful. Regards Pavel > -- > Jim C. Nasby, Data Architect j...@nasby.net > 512.569.9461 (cell) http://jim.nasby.net >
