Prev: NaN/Inf fix for ECPG
Next: XQuery support
From: Hitoshi Harada on 16 Feb 2010 07:52
2010/2/16 Pavel Stehule <pavel.stehule(a)gmail.com>:
> 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
the function is volatile. Also, I don't see how do you choose function
argument values even in immutable cases.

Regards,

--
Hitoshi Harada

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Pavel Stehule on 16 Feb 2010 08:44
2010/2/16 Hitoshi Harada <umi.tanuki(a)gmail.com>:
> 2010/2/16 Pavel Stehule <pavel.stehule(a)gmail.com>:
>> 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
> the function is volatile. Also, I don't see how do you choose function
> argument values even in immutable cases.

It is issue only for dynamic sql and polymorphic functions. But for
all others we can do full check in validation stage. I thinking about
similar tool to lint - just for plpgsql function. It cannot detect all
bugs, but it can diagnose 99% of possible issues.

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 plan
generation instead.

Regards
Pavel Stehule

>
> Regards,
>
> --
> Hitoshi Harada
>

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on 16 Feb 2010 10:49
Pavel Stehule <pavel.stehule(a)gmail.com> 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 plan
> generation instead.

Previous proposals in this line have foundered on examples like
functions that create a temp table and then manipulate it.
Only DDL-free functions can be statically checked in the way
you suggest.

Between that and the parameter-related limitations that Hitoshi
points out, the use case seems to be rather restricted ...

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Hitoshi Harada on 16 Feb 2010 10:55
2010/2/16 Pavel Stehule <pavel.stehule(a)gmail.com>:
> 2010/2/16 Hitoshi Harada <umi.tanuki(a)gmail.com>:
>> 2010/2/16 Pavel Stehule <pavel.stehule(a)gmail.com>:
>>> 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
>> the function is volatile. Also, I don't see how do you choose function
>> argument values even in immutable cases.
>
> It is issue only for dynamic sql and polymorphic functions. But for
> all others we can do full check in validation stage. I thinking about
> similar tool to lint - just for plpgsql function. It cannot detect all
> bugs, but it can diagnose 99% of possible issues.
>
> 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 plan
> generation instead.

Hmm, type mismatching can be checked by your suggestion, but that's
it. The true answer to your original post might be "write unit test",
isn't it?

Regards,


--
Hitoshi Harada

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Pavel Stehule on 16 Feb 2010 11:09
2010/2/16 Tom Lane <tgl(a)sss.pgh.pa.us>:
> Pavel Stehule <pavel.stehule(a)gmail.com> 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 plan
>> generation instead.
>
> Previous proposals in this line have foundered on examples like
> functions that create a temp table and then manipulate it.
> Only DDL-free functions can be statically checked in the way
> you suggest.
>

No and yes.

yes - 100% test are possible only on a) DDL free functions, b) 100%
static schema.
no - in reality schema is usually stable and we are able to check sql
using stable schema.

This proposal isn't about ideal checking - it isn't possible. It is
about the maximum from what is possible.

I would to identify bugs in not often using execution path before
production. This case is real. Stored procedures works well and after
half of year we finding broken identifiers in some queries.

> Between that and the parameter-related limitations that Hitoshi
> points out, the use case seems to be rather restricted ...

why? why is it better? do you have a way for runtime checking of all
possible execution path?

regards
Pavel

>
>                        regards, tom lane
>

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

 | 
Pages: 1
Prev: NaN/Inf fix for ECPG
Next: XQuery support