2010/2/16 Tom Lane :
> Pavel Stehule writes:
>> I don't would to execute function - it is useless because you need
>> good UI for execution all path. My idea is different. gram.y has
>> check_sql_expr rutine. This is used for parser checking every static
>> SQL fragment in plpgsql function. With s
2010/2/16 Pavel Stehule :
> 2010/2/16 Hitoshi Harada :
>> 2010/2/16 Pavel Stehule :
>>> I think, so these problem have to be identified in compile stage - but
>>> it can be too strict for all (and can slow down production) - it is
>>> reason for plugin.
>>>
>>> What do you think about this idea?
>>
Pavel Stehule writes:
> I don't would to execute function - it is useless because you need
> good UI for execution all path. My idea is different. gram.y has
> check_sql_expr rutine. This is used for parser checking every static
> SQL fragment in plpgsql function. With some hook we can do full pla
2010/2/16 Hitoshi Harada :
> 2010/2/16 Pavel Stehule :
>> I think, so these problem have to be identified in compile stage - but
>> it can be too strict for all (and can slow down production) - it is
>> reason for plugin.
>>
>> What do you think about this idea?
>
> How do you identify them? Runnin
2010/2/16 Pavel Stehule :
> I think, so these problem have to be identified in compile stage - but
> it can be too strict for all (and can slow down production) - it is
> reason for plugin.
>
> What do you think about this idea?
How do you identify them? Running function body cannot be applied if
Hello
I thinking about more restrictive query and expression checking than
now. Used parser checking isn't enough - so some possible bugs can be
detected in production stage. Other problem is using any expression
as SELECT expr. The request on validation can be different and it is
probably for m
