On Wed, Dec 11, 2013 at 10:40 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Amit Kapila amit.kapil...@gmail.com writes:
On Tue, Dec 10, 2013 at 12:15 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Now, PG has no any tool for checking dependency between functions and other
objects.
Isn't that
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 amit.kapil...@gmail.com napsal(a):
On Wed, Dec 11, 2013 at 10:40 AM, Tom Lane t...@sss.pgh.pa.us
On Tue, Dec 10, 2013 at 1:45 AM, Pavel Stehule pavel.steh...@gmail.com 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
Robert Haas robertmh...@gmail.com 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
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 think
On Tue, Dec 10, 2013 at 12:15 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
2013/12/10 Amit Kapila amit.kapil...@gmail.com
On Mon, Dec 9, 2013 at 10:54 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2013/12/9 Amit Kapila amit.kapil...@gmail.com
There are two points, that should be
Amit Kapila amit.kapil...@gmail.com writes:
On Tue, Dec 10, 2013 at 12:15 PM, Pavel Stehule pavel.steh...@gmail.com
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
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 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
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
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
On Mon, Dec 9, 2013 at 10:54 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
2013/12/9 Amit Kapila amit.kapil...@gmail.com
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)
2013/12/9 Peter Eisentraut pete...@gmx.net
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
2013/12/10 Amit Kapila amit.kapil...@gmail.com
On Mon, Dec 9, 2013 at 10:54 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2013/12/9 Amit Kapila amit.kapil...@gmail.com
There are two points, that should be solved
a) introduction a dependency to other object in schema - now
There is still valid a variant to move check function to contrib for fist
moment.
Regards
Pavel
2013/12/7 Pavel Stehule pavel.steh...@gmail.com
Hello
thank you for review
2013/12/7 Steve Singer st...@ssinger.info
On 08/22/2013 02:02 AM, Pavel Stehule wrote:
rebased
Regards
Pavel
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
2013/12/8 Peter Eisentraut pete...@gmx.net
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
On Sun, Dec 8, 2013 at 10:31 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
2013/12/8 Peter Eisentraut pete...@gmx.net
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.
2013/12/9 Amit Kapila amit.kapil...@gmail.com
On Sun, Dec 8, 2013 at 10:31 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2013/12/8 Peter Eisentraut pete...@gmx.net
In my opinion, the idea of having a separate lint checker for a language
is antiquated. If there are problems,
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
Hello
thank you for review
2013/12/7 Steve Singer st...@ssinger.info
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
rebased
Regards
Pavel
2013/8/22 Peter Eisentraut pete...@gmx.net
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
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
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$
Hello all
2013/3/26 Tom Lane t...@sss.pgh.pa.us:
Josh Berkus j...@agliodbs.com 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
Josh Berkus j...@agliodbs.com 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
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
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
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
-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_function - rebase for 9.3
Hello
Petr Jelinek pjmo...@pjmodos.net 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,
-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 pjmo...@pjmodos.net writes:
I was wondering
2013/1/26 Petr Jelinek pjmo...@pjmodos.net:
-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 pjmo
Petr Jelinek pjmo...@pjmodos.net 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,
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 for some reason we're specifying
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 pavel.steh...@gmail.com:
Hello
I am sending a updated version - now it is prepared
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 sel...@chesnok.com:
Hi!
On Tue, Jun 26, 2012 at
Selena Deckelmann sel...@chesnok.com 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
On 10/07/2012 11:25 AM, Tom Lane wrote:
Selena Deckelmann sel...@chesnok.com 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
42 matches
Mail list logo
