On Wed, 2013-03-27 at 23:25 +0100, Pavel Stehule wrote:
> I redesigned output from plpgsql_check_function. Now, it returns table
> everytime.
> Litlle bit code simplification.
This patch is in the 2013-09 commitfest but needs a rebase.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@pos
rebased
Regards
Pavel
2013/8/22 Peter Eisentraut
> On Wed, 2013-03-27 at 23:25 +0100, Pavel Stehule wrote:
> > I redesigned output from plpgsql_check_function. Now, it returns table
> > everytime.
> > Litlle bit code simplification.
>
> This patch is in the 2013-09 commitfest but needs a reba
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Pavel Stehule
> Sent: 28 November 2012 11:07
> To: Selena Deckelmann
> Cc: PostgreSQL Hackers
> Subject: Re: [HACKERS] plpgsql_check_func
"Petr Jelinek" writes:
> I was wondering if maybe this could be split to 2 separate patches, one would
> be all the changes to the existing plpgsql code - rename delete_function to
> plpgsql_delete_function and extern plpgsql_delete_function,
> copy_plpgsql_datum, plpgsql_estate_setup, plpgsql
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Tom Lane
> Sent: 26 January 2013 18:16
> Subject: Re: [HACKERS] plpgsql_check_function - rebase for 9.3
>
> "Petr Jelinek" writes:
&g
2013/1/26 Petr Jelinek :
>> -Original Message-
>> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
>> ow...@postgresql.org] On Behalf Of Tom Lane
>> Sent: 26 January 2013 18:16
>> Subject: Re: [HACKERS] plpgsql_check_function - rebase for 9.
"Petr Jelinek" writes:
>> What exactly do you have in mind there? The way we load extensions, they
>> can't (AFAIK) see each other's defined symbols, so you couldn't really make
>> an independent extension that would call functions in plpgsql. This is not
>> really open for debate, either, as ch
I wrote:
> [ pokes around... ] Hm, it appears that that does work on Linux,
> because for some reason we're specifying RTLD_GLOBAL to dlopen().
> TBH that seems like a truly horrid idea that we should reconsider.
A bit of research in the archives revealed that we're using it because
back in 2001,
> -Original Message-
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> Sent: 26 January 2013 20:12
> Subject: Re: [HACKERS] plpgsql_check_function - rebase for 9.3
>
> I wrote:
> > [ pokes around... ] Hm, it appears that that does work on Linux,
> > because fo
On 1/26/13 1:53 PM, Tom Lane wrote:
> [ pokes around... ] Hm, it appears that that does work on Linux,
> because for some reason we're specifying RTLD_GLOBAL to dlopen().
> TBH that seems like a truly horrid idea that we should reconsider.
> Aside from the danger of unexpected symbol collisions be
On 01/28/2013 10:11 AM, Peter Eisentraut wrote:
On 1/26/13 1:53 PM, Tom Lane wrote:
[ pokes around... ] Hm, it appears that that does work on Linux,
because for some reason we're specifying RTLD_GLOBAL to dlopen().
TBH that seems like a truly horrid idea that we should reconsider.
Aside from t
Selena Deckelmann writes:
> This also represents my inaugural use of pg_bsd_indent. I ran it on
> pl_check.c - which made things mostly better. Happy to try and fix it
> up more if someone can explain to me what (if anything) I did
> incorrectly when using it.
It looks like you didn't give it a t
On 10/07/2012 11:25 AM, Tom Lane wrote:
Selena Deckelmann writes:
This also represents my inaugural use of pg_bsd_indent. I ran it on
pl_check.c - which made things mostly better. Happy to try and fix it
up more if someone can explain to me what (if anything) I did
incorrectly when using it.
Hello
I am sending a updated version - now it is prepared for event triggers
and it is little bit more robust
I run pgindent, but I have no experience with it, so I am not sure about success
Regards
Pavel Stehule
2012/10/7 Selena Deckelmann :
> Hi!
>
> On Tue, Jun 26, 2012 at 1:19 AM, Pavel S
Hello
a some updated version
* possibility to raise (and filter) performance warnings - detects IO castings
* detects assign composite value to scalar variable
Regards
Pavel Stehule
2012/11/27 Pavel Stehule :
> Hello
>
> I am sending a updated version - now it is prepared for event triggers
>
Hello
I though about any possibility how to reduce a size of this patch.
I see a one solution - if we would not support a detection of multiple
errors - it stops on first error, we can push this code to compilation
stage.
a plpgsql_validator can be overloaded by function
plpgsql_validator(oid,
Folks,
Where are we with this patch? I'm a bit unclear from the discussion on
whether it passes muster or not. Things seem to have petered out.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
Josh Berkus writes:
> Where are we with this patch? I'm a bit unclear from the discussion on
> whether it passes muster or not. Things seem to have petered out.
I took another look at this patch tonight. I think the thing that is
bothering everybody (including Pavel) is that as submitted, pl_c
Hello all
2013/3/26 Tom Lane :
> Josh Berkus writes:
>> Where are we with this patch? I'm a bit unclear from the discussion on
>> whether it passes muster or not. Things seem to have petered out.
>
> I took another look at this patch tonight. I think the thing that is
> bothering everybody (in
Hello
I redesigned output from plpgsql_check_function. Now, it returns table
everytime.
Litlle bit code simplification.
postgres=# \sf fx
CREATE OR REPLACE FUNCTION public.fx(integer)
RETURNS integer
LANGUAGE plpgsql
AS $function$
BEGIN
RETURN (SELECT a FROM t1 WHERE b < $1);
END;
$function$
On 08/22/2013 02:02 AM, Pavel Stehule wrote:
rebased
Regards
Pavel
This patch again needs a rebase, it no longer applies cleanly.
plpgsql_estate_setup now takes a shared estate parameter and the call in
pl_check needs that. I passed NULL in and things seem to work.
I think this is anot
Hello
thank you for review
2013/12/7 Steve Singer
> On 08/22/2013 02:02 AM, Pavel Stehule wrote:
>
>> rebased
>>
>> Regards
>>
>> Pavel
>>
>> This patch again needs a rebase, it no longer applies cleanly.
> plpgsql_estate_setup now takes a shared estate parameter and the call in
> pl_check ne
There is still valid a variant to move check function to contrib for fist
moment.
Regards
Pavel
2013/12/7 Pavel Stehule
> Hello
>
> thank you for review
>
>
> 2013/12/7 Steve Singer
>
>> On 08/22/2013 02:02 AM, Pavel Stehule wrote:
>>
>>> rebased
>>>
>>> Regards
>>>
>>> Pavel
>>>
>>> This p
In my opinion, the idea of having a separate lint checker for a language
is antiquated. If there are problems, they should be diagnosed at
compile time or run time. You can add options about warning levels or
strictness if there are concerns about which diagnostics are
appropriate.
>
>
On Sun, 2013-12-08 at 09:45 +0100, Pavel Stehule wrote:
> There is still valid a variant to move check function to contrib for
> fist moment.
If we are not happy with the code or the interface, then moving it to
contrib is not a solution. We are still committed to main things in
contrib indefini
2013/12/8 Peter Eisentraut
> In my opinion, the idea of having a separate lint checker for a language
> is antiquated. If there are problems, they should be diagnosed at
> compile time or run time. You can add options about warning levels or
> strictness if there are concerns about which diagno
On Sun, Dec 8, 2013 at 10:31 PM, Pavel Stehule wrote:
>
>
>
> 2013/12/8 Peter Eisentraut
>>
>> In my opinion, the idea of having a separate lint checker for a language
>> is antiquated. If there are problems, they should be diagnosed at
>> compile time or run time. You can add options about war
2013/12/9 Amit Kapila
> On Sun, Dec 8, 2013 at 10:31 PM, Pavel Stehule
> wrote:
> >
> >
> >
> > 2013/12/8 Peter Eisentraut
> >>
> >> In my opinion, the idea of having a separate lint checker for a language
> >> is antiquated. If there are problems, they should be diagnosed at
> >> compile time
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
2013/12/9 Jim Nasby
> 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,
On 12/9/13 1:08 PM, Pavel Stehule wrote:
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 w
On 12/8/13, 12:01 PM, Pavel Stehule wrote:
> But still I have no idea, how to push check without possible slowdown
> execution with code duplication
Create a GUC parameter plpgsql.slow_checks or whatever (perhaps more
specific), which people can turn on when they run their test suites.
This doesn
On Mon, Dec 9, 2013 at 10:54 AM, Pavel Stehule wrote:
> 2013/12/9 Amit Kapila
>>
>> >
>> > There are two points, that should be solved
>> >
>> > a) introduction a dependency to other object in schema - now CREATE
>> > FUNCTION
>> > is fully independent on others
>> >
>> > b) slow start - if we ch
2013/12/9 Peter Eisentraut
> On 12/8/13, 12:01 PM, Pavel Stehule wrote:
> > But still I have no idea, how to push check without possible slowdown
> > execution with code duplication
>
> Create a GUC parameter plpgsql.slow_checks or whatever (perhaps more
> specific), which people can turn on when
2013/12/10 Amit Kapila
> On Mon, Dec 9, 2013 at 10:54 AM, Pavel Stehule
> wrote:
> > 2013/12/9 Amit Kapila
> >>
> >> >
> >> > There are two points, that should be solved
> >> >
> >> > a) introduction a dependency to other object in schema - now CREATE
> >> > FUNCTION
> >> > is fully independent
On Tue, Dec 10, 2013 at 1:45 AM, Pavel Stehule wrote:
> Now, PG has no any tool for checking dependency between functions and other
> objects. What has positive effects - we have very simply deploying, that
> works in almost use cases very well - and works with our temporary tables
> implementatio
Robert Haas writes:
> This is a very good point. Annotating the function itself with
> markers that cause it to be more strictly checked will create a
> dump/reload problem that we won't enjoy solving. The decision to
> check the function more strictly or not would need to be based on some
> kin
On 12/10/2013 12:50 PM, Tom Lane wrote:
> One would hope that turning off check_function_bodies would be sufficient
> to disable any added checking, though, so I don't see this being a problem
> for pg_dump. But there might be other scenarios where an additional knob
> would be useful.
I can't th
On Tue, Dec 10, 2013 at 12:15 PM, Pavel Stehule wrote:
> 2013/12/10 Amit Kapila
>> On Mon, Dec 9, 2013 at 10:54 AM, Pavel Stehule
>> wrote:
>> > 2013/12/9 Amit Kapila
>> >> > There are two points, that should be solved
>> >> >
>> >> > a) introduction a dependency to other object in schema - now
Amit Kapila writes:
> On Tue, Dec 10, 2013 at 12:15 PM, Pavel Stehule
> wrote:
>> Now, PG has no any tool for checking dependency between functions and other
>> objects.
> Isn't that already done for SQL function's (fmgr_sql_validator)?
Pavel's point is that the only way to find out if the val
On Wed, Dec 11, 2013 at 10:40 AM, Tom Lane wrote:
> Amit Kapila writes:
>> On Tue, Dec 10, 2013 at 12:15 PM, Pavel Stehule
>> wrote:
>>> Now, PG has no any tool for checking dependency between functions and other
>>> objects.
>
>> Isn't that already done for SQL function's (fmgr_sql_validator)?
I dislike it. a too early check means a issues with temporary tables and
mainy new dependency between functions in complex projects. It is some what
we don't want.
Dne 12. 12. 2013 5:30 "Amit Kapila" napsal(a):
> On Wed, Dec 11, 2013 at 10:40 AM, Tom Lane wrote:
> > Amit Kapila writes:
> >> On
42 matches
Mail list logo
