Hello
2012/4/4 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
On 04.04.2012 19:32, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes:
I don't think I'm getting my point across by explaining, so here's a
modified version of the patch that does what I was
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
I don't think I'm getting my point across by explaining, so here's a
modified version of the patch that does what I was trying to say.
Minor side point: some of the diff noise in this patch comes from
On 04.04.2012 19:32, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes:
I don't think I'm getting my point across by explaining, so here's a
modified version of the patch that does what I was trying to say.
Minor side point: some of the diff noise in this patch
2012/4/4 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
On 04.04.2012 19:32, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes:
I don't think I'm getting my point across by explaining, so here's a
modified version of the patch that does what I was trying
2012/4/4 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
On 30.03.2012 12:36, Pavel Stehule wrote:
2012/3/28 Heikki Linnakangasheikki.linnakan...@enterprisedb.com:
In prepare_expr(), you use a subtransaction to catch any ERRORs that
happen
during parsing the expression. That's a
Hello
2012/3/28 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
Ok, seems that the API issue is settled, so I'm now looking at the code
actually doing the checking. My first impression is that this is a lot of
code. Can we simplify it?
I played with this and It is not be reduced
On 28.03.2012 23:54, Pavel Stehule wrote:
2012/3/28 Heikki Linnakangasheikki.linnakan...@enterprisedb.com:
In prepare_expr(), you use a subtransaction to catch any ERRORs that happen
during parsing the expression. That's a good idea, and I think many of the
check_* functions could be greatly
2012/3/29 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
On 28.03.2012 23:54, Pavel Stehule wrote:
2012/3/28 Heikki Linnakangasheikki.linnakan...@enterprisedb.com:
In prepare_expr(), you use a subtransaction to catch any ERRORs that
happen
during parsing the expression. That's a
Ok, seems that the API issue is settled, so I'm now looking at the code
actually doing the checking. My first impression is that this is a lot
of code. Can we simplify it?
Since this is deeply integrated into the PL/pgSQL interpreter, I was
expecting that this would run through the normal
Hello
2012/3/28 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
Ok, seems that the API issue is settled, so I'm now looking at the code
actually doing the checking. My first impression is that this is a lot of
code. Can we simplify it?
I am afraid so there are not a big space for
2012/3/11 Petr Jelinek pjmo...@pjmodos.net:
On 03/10/2012 04:36 PM, Pavel Stehule wrote:
and there some cleaned version
Reran my tests and adjusted docs a bit, tbh I considered the previous
versions way more useful but even in this form it's nice and useful
functionality.
remove two
On 03/10/2012 04:36 PM, Pavel Stehule wrote:
and there some cleaned version
Reran my tests and adjusted docs a bit, tbh I considered the previous
versions way more useful but even in this form it's nice and useful
functionality.
Regards
Petr Jelinek
plpgsql_check_function2.diff.gz
2012/3/11 Petr Jelinek pjmo...@pjmodos.net:
On 03/10/2012 04:36 PM, Pavel Stehule wrote:
and there some cleaned version
Reran my tests and adjusted docs a bit, tbh I considered the previous
versions way more useful but even in this form it's nice and useful
functionality.
thank you -
Hello
2012/3/10 Tom Lane t...@sss.pgh.pa.us:
Peter Eisentraut pete...@gmx.net writes:
But then I would have to map all language-specific error reports to some
SQL error scheme, which is not only cumbersome but pretty useless. For
example, a Python programmer will be familiar with the typical
here is draft
and there some cleaned version
Regards
Pavel Stehule
regards, tom lane
plpgsql_check_function.diff.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On tor, 2012-03-08 at 23:15 +0100, Pavel Stehule wrote:
But you propose some little bit different than is current plpgsql
checker and current design.
Is it? Why? It looks like exactly the same thing, except that the
interfaces you propose are tightly geared toward checking SQL-like
languages,
On tor, 2012-03-08 at 19:19 -0500, Robert Haas wrote:
On Thu, Mar 8, 2012 at 4:54 PM, Peter Eisentraut pete...@gmx.net wrote:
* It's not terribly important to me to be able to run checkers
separately. If I wanted to do that, I would just disable or
remove the checker.
On Fri, Mar 9, 2012 at 3:15 PM, Peter Eisentraut pete...@gmx.net wrote:
On tor, 2012-03-08 at 19:19 -0500, Robert Haas wrote:
On Thu, Mar 8, 2012 at 4:54 PM, Peter Eisentraut pete...@gmx.net wrote:
* It's not terribly important to me to be able to run checkers
separately. If I
Robert Haas robertmh...@gmail.com writes:
On Fri, Mar 9, 2012 at 3:15 PM, Peter Eisentraut pete...@gmx.net wrote:
Well, the more I think about it and look at this patch, the more I think
that this would be complete overkill and possibly quite useless for my
purposes. I can implement the
2012/3/9 Peter Eisentraut pete...@gmx.net:
On tor, 2012-03-08 at 23:15 +0100, Pavel Stehule wrote:
But you propose some little bit different than is current plpgsql
checker and current design.
Is it? Why? It looks like exactly the same thing, except that the
interfaces you propose are
Pavel Stehule pavel.steh...@gmail.com writes:
2012/3/9 Peter Eisentraut pete...@gmx.net:
What would be the qualifications for being an internal or an external
checker? Why couldn't your plpgsql checker be an external checker?
plpgsql checker cannot be external checker, because it reuse 70%
On Fri, Mar 9, 2012 at 3:33 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If we're going to go the ad-hoc route, there seems little reason to be
considering a core patch at all. Freestanding checkers could just as
well be independent projects.
I completely agree. I think there is little reason to
2012/3/9 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2012/3/9 Peter Eisentraut pete...@gmx.net:
What would be the qualifications for being an internal or an external
checker? Why couldn't your plpgsql checker be an external checker?
plpgsql checker cannot be
On Fri, Mar 9, 2012 at 5:09 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
Well, that just means that it'd be a good idea for that function to be
supplied by the same shared library that supplies the plpgsql execution
functions. There wouldn't need to be any connection that the core
system
2012/3/9 Robert Haas robertmh...@gmail.com:
On Fri, Mar 9, 2012 at 5:09 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
Well, that just means that it'd be a good idea for that function to be
supplied by the same shared library that supplies the plpgsql execution
functions. There wouldn't
On Fri, Mar 9, 2012 at 5:31 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
ok - it has sense, but it has sense only with some smart statements
(like CHECK). Without these statements I have to directly call checker
function and then concept of generalised checkers has not sense.
I agree.
--
On fre, 2012-03-09 at 21:54 +0100, Pavel Stehule wrote:
no, you can check any PL language - and output result is based on SQL
Errors, so it should be enough for all PL too.
But then I would have to map all language-specific error reports to some
SQL error scheme, which is not only cumbersome
On fre, 2012-03-09 at 15:33 -0500, Tom Lane wrote:
What I've wanted from this patch from the beginning was a
common framework. That is, I want to be able to write something like
SELECT check_function(oid) FROM pg_proc WHERE proowner = 'tgl'
and have it just work for all languages for
Peter Eisentraut pete...@gmx.net writes:
But then I would have to map all language-specific error reports to some
SQL error scheme, which is not only cumbersome but pretty useless. For
example, a Python programmer will be familiar with the typical output
that pylint produces and how to fix
2012/3/10 Tom Lane t...@sss.pgh.pa.us:
Peter Eisentraut pete...@gmx.net writes:
But then I would have to map all language-specific error reports to some
SQL error scheme, which is not only cumbersome but pretty useless. For
example, a Python programmer will be familiar with the typical output
Robert Haas wrote:
Well, I guess I'm still of the opinion that the real question is
whether the particular lint checks that Pavel's implemented are good
and useful things. Has anyone spent any time looking at *that*?
Actually, I did when I reviewed the patch the first time round.
I think that
On 03/08/2012 08:35 AM, Pavel Stehule wrote:
Here is updated patch (with regress tests, with documentation).
I removed a CHECK FUNCTION and CHECK TRIGGER statements and replaced
it by pg_check_function and pg_check_trigger like Tom proposed.
The core of this patch is same - plpgsql checker,
On ons, 2012-03-07 at 12:31 -0500, Robert Haas wrote:
I might agree with you if we had more than one checker function, but
right now we are proposing to implement this for PL/pgsql and only
PL/pgsql. It seems to me that we can add that when and if a second
checker function shows up, if it
On tor, 2012-03-08 at 10:49 +0100, Albe Laurenz wrote:
Actually, I did when I reviewed the patch the first time round.
I think that the checks implemented are clearly good and useful,
since any problem reported will lead to an error at runtime if
a certain code path in the function is taken.
2012/3/8 Peter Eisentraut pete...@gmx.net:
On tor, 2012-03-08 at 10:49 +0100, Albe Laurenz wrote:
Actually, I did when I reviewed the patch the first time round.
I think that the checks implemented are clearly good and useful,
since any problem reported will lead to an error at runtime if
a
2012/3/8 Peter Eisentraut pete...@gmx.net:
On ons, 2012-03-07 at 12:31 -0500, Robert Haas wrote:
I might agree with you if we had more than one checker function, but
right now we are proposing to implement this for PL/pgsql and only
PL/pgsql. It seems to me that we can add that when and if a
On Thu, Mar 8, 2012 at 4:54 PM, Peter Eisentraut pete...@gmx.net wrote:
* It's not terribly important to me to be able to run checkers
separately. If I wanted to do that, I would just disable or
remove the checker.
Does this requirement mean that you want to essentially
On Wed, Mar 7, 2012 at 12:17 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
Robert, please, can you comment to this issue? And other, please. I am
able to fix syntax to any form where we will have agreement.
Well, so far I don't see that anyone has offered a compelling reason
why this needs
Robert Haas robertmh...@gmail.com writes:
Just to be clear, I am not proposing that we get rid of CHECK TRIGGER
and keep CHECK FUNCTION. I'm proposing that we get rid of all of the
dedicated syntax support, and expose it all through one or more
SQL-callable functions.
This seems entirely
2012/3/7 Robert Haas robertmh...@gmail.com:
On Wed, Mar 7, 2012 at 12:17 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Robert, please, can you comment to this issue? And other, please. I am
able to fix syntax to any form where we will have agreement.
Well, so far I don't see that anyone
On Wed, Mar 7, 2012 at 12:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If we need both
plpgsql_check_function(procoid) and plpgsql_check_trigger(tgoid), no
problem.
FWIW, I would suggest check_trigger(regclass, name) not tgoid, because
we do not have a regtrigger convenience type (and I don't
2012/3/7 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
Just to be clear, I am not proposing that we get rid of CHECK TRIGGER
and keep CHECK FUNCTION. I'm proposing that we get rid of all of the
dedicated syntax support, and expose it all through one or more
Robert Haas robertmh...@gmail.com writes:
On Wed, Mar 7, 2012 at 12:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
More importantly, I do not agree with requiring the user to specify the
language name --- that is, it should be check_function(procoid) and have
that look up a language-specific
2012/3/7 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
On Wed, Mar 7, 2012 at 12:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
More importantly, I do not agree with requiring the user to specify the
language name --- that is, it should be check_function(procoid) and have
On Wed, Mar 7, 2012 at 2:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Mar 7, 2012 at 12:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
More importantly, I do not agree with requiring the user to specify the
language name --- that is, it should be
2012/3/7 Robert Haas robertmh...@gmail.com:
On Wed, Mar 7, 2012 at 2:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Mar 7, 2012 at 12:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
More importantly, I do not agree with requiring the user to specify the
Robert Haas robertmh...@gmail.com writes:
Well, I guess I'm still of the opinion that the real question is
whether the particular lint checks that Pavel's implemented are good
and useful things. Has anyone spent any time looking at *that*? I'm
not going to stand here and hold my breath over
Hello
2012/3/7 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
Just to be clear, I am not proposing that we get rid of CHECK TRIGGER
and keep CHECK FUNCTION. I'm proposing that we get rid of all of the
dedicated syntax support, and expose it all through one or more
Hello
2012/3/7 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
Just to be clear, I am not proposing that we get rid of CHECK TRIGGER
and keep CHECK FUNCTION. I'm proposing that we get rid of all of the
dedicated syntax support, and expose it all through one or more
Hello
When I try to look on some multicheck form:
a) CHECK FUNCTION ALL ON table_name
b) CHECK TRIGGER ALL ON table_name
then more natural form is @b (for me). Personally, I can live with
one, both or second form, although I prefer CHECK TRIGGER.
I though some time more.
if somebody
Hello
Robert, please, can you comment to this issue? And other, please. I am
able to fix syntax to any form where we will have agreement.
Regards
Pavel
2012/3/6 Pavel Stehule pavel.steh...@gmail.com:
Hello
When I try to look on some multicheck form:
a) CHECK FUNCTION ALL ON table_name
On Sat, Mar 3, 2012 at 9:23 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Uh! Now that I read this I realize that what you're supposed to give to
CHECK TRIGGER is the trigger name, not the function name! In that
light, using CHECK FUNCTION for this doesn't make a lot of sense.
Okay,
2012/3/5 Robert Haas robertmh...@gmail.com:
On Sat, Mar 3, 2012 at 9:23 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Uh! Now that I read this I realize that what you're supposed to give to
CHECK TRIGGER is the trigger name, not the function name! In that
light, using CHECK FUNCTION
Robert Haas robertmh...@gmail.com writes:
I confess to some bafflement about why we need dedicated syntax for
this, or even any kind of core support at all. What would be wrong
with defining a function that takes regprocedure as an argument and
does whatever? Sure, it's nicer syntax, but
On Mon, Mar 5, 2012 at 11:41 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I confess to some bafflement about why we need dedicated syntax for
this, or even any kind of core support at all. What would be wrong
with defining a function that takes regprocedure
2012/3/5 Robert Haas robertmh...@gmail.com:
On Mon, Mar 5, 2012 at 11:41 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I confess to some bafflement about why we need dedicated syntax for
this, or even any kind of core support at all. What would be wrong
2012/3/5 Robert Haas robertmh...@gmail.com:
On Sat, Mar 3, 2012 at 9:23 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Uh! Now that I read this I realize that what you're supposed to give to
CHECK TRIGGER is the trigger name, not the function name! In that
light, using CHECK FUNCTION
Alvaro Herrera alvhe...@alvh.no-ip.org writes:
Pavel's patch for CHECK FUNCTION is adding another command besides that
one, which is CHECK TRIGGER. The idea behind this is that you give it
the relation to which the trigger is attached in addition to the trigger
name, and it checks the
Excerpts from Tom Lane's message of sáb mar 03 23:00:26 -0300 2012:
Alvaro Herrera alvhe...@alvh.no-ip.org writes:
Pavel's patch for CHECK FUNCTION is adding another command besides that
one, which is CHECK TRIGGER. The idea behind this is that you give it
the relation to which the
59 matches
Mail list logo
