2013/11/27 Peter Eisentraut
> On Tue, 2013-11-19 at 10:40 -0500, Robert Haas wrote:
> > I think the goal was to get to RAISE ASSERT
> > WHEN ...; then, if assertions are off, you do nothing; if they're on,
> > you error. IF condition THEN RAISE..." isn't a suitable surrogate in
> > that case bec
On Tue, 2013-11-19 at 10:40 -0500, Robert Haas wrote:
> I think the goal was to get to RAISE ASSERT
> WHEN ...; then, if assertions are off, you do nothing; if they're on,
> you error. IF condition THEN RAISE..." isn't a suitable surrogate in
> that case because you incur the overhead of testing t
2013/11/19 Robert Haas
> On Tue, Nov 19, 2013 at 10:59 AM, Pavel Stehule
> wrote:
> >> Now that having been said, I'm a bit wary of adding every new frammish
> >> someone suggests to PL/pgsql. Many of the things we've added recently
> >> are things I anticipate that I'll never use.
> >
> > lot
On Tue, Nov 19, 2013 at 10:59 AM, Pavel Stehule wrote:
>> Now that having been said, I'm a bit wary of adding every new frammish
>> someone suggests to PL/pgsql. Many of the things we've added recently
>> are things I anticipate that I'll never use.
>
> lot of features are popular with some delay
2013/11/19 Robert Haas
> On Sun, Nov 17, 2013 at 5:10 PM, Tom Lane wrote:
> > Pavel Stehule writes:
> >> [ rebased patch for RAISE WHEN ]
> >
> > I have to say I do not see the point of this. It does nothing you
> > can't do already with "IF condition THEN RAISE ...". And frankly
> > the RAIS
On Sun, Nov 17, 2013 at 5:10 PM, Tom Lane wrote:
> Pavel Stehule writes:
>> [ rebased patch for RAISE WHEN ]
>
> I have to say I do not see the point of this. It does nothing you
> can't do already with "IF condition THEN RAISE ...". And frankly
> the RAISE statement has got too darn many optio
2013/11/17 Tom Lane
> Pavel Stehule writes:
> > [ rebased patch for RAISE WHEN ]
>
> I have to say I do not see the point of this. It does nothing you
> can't do already with "IF condition THEN RAISE ...". And frankly
> the RAISE statement has got too darn many options already. We don't
> nee
Pavel Stehule writes:
> [ rebased patch for RAISE WHEN ]
I have to say I do not see the point of this. It does nothing you
can't do already with "IF condition THEN RAISE ...". And frankly
the RAISE statement has got too darn many options already. We don't
need yet more cruft on it that we'll h
rebased patch
Regards
Pavel
2013/11/14 Peter Eisentraut
> On Wed, 2013-10-09 at 18:57 +0200, Pavel Stehule wrote:
> > here is a patch for RAISE WHEN clause
>
> Your patch needs to be rebased.
>
>
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index ca2c2b5..d6845d7 100644
On Wed, 2013-10-09 at 18:57 +0200, Pavel Stehule wrote:
> here is a patch for RAISE WHEN clause
Your patch needs to be rebased.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Oct 9, 2013 at 12:57 PM, Pavel Stehule wrote:
> here is a patch for RAISE WHEN clause
This is in effect a whole new patch by a different author. Please
submit it to the next CommitFest; I'm marking the entry for
"Assertions in PL/PgSQL" as "Returned with Feedback".
--
Robert Haas
Enter
Hello
2013/9/24 Robert Haas
> On Mon, Sep 23, 2013 at 5:48 AM, Amit Khandekar
> wrote:
> >>> The assert levels sound a bit like a user might be confused by these
> >>> levels being present at both places: In the RAISE syntax itself, and
> the
> >>> assert GUC level. But I like the syntax. How
On Mon, Sep 23, 2013 at 5:48 AM, Amit Khandekar
wrote:
>>> The assert levels sound a bit like a user might be confused by these
>>> levels being present at both places: In the RAISE syntax itself, and the
>>> assert GUC level. But I like the syntax. How about keeping the ASSERT
>>> keyword option
On 23 September 2013 14:33, Pavel Stehule wrote:
>
>
>
> 2013/9/23 Amit Khandekar
>
>>
>>
>>
>> On 23 September 2013 10:10, Pavel Stehule wrote:
>>
>>>
>>>
>>>
>>> 2013/9/22 Jaime Casanova
>>>
El 21/09/2013 17:16, "Jaime Casanova" escribió:
>
> On Fri, Sep 20, 2013 at
2013/9/23 Marko Tiikkaja
> On 9/23/13 11:12 AM, I wrote:
>
>> On 9/23/13 11:01 AM, Amit Khandekar wrote:
>>
>>> The assert levels sound a bit like a user might be confused by these
>>> levels
>>> being present at both places: In the RAISE syntax itself, and the assert
>>> GUC level. But I like t
On 9/23/13 11:12 AM, I wrote:
On 9/23/13 11:01 AM, Amit Khandekar wrote:
The assert levels sound a bit like a user might be confused by these levels
being present at both places: In the RAISE syntax itself, and the assert
GUC level. But I like the syntax. How about keeping the ASSERT keyword
op
On 9/23/13 11:01 AM, Amit Khandekar wrote:
The assert levels sound a bit like a user might be confused by these levels
being present at both places: In the RAISE syntax itself, and the assert
GUC level. But I like the syntax. How about keeping the ASSERT keyword
optional ? When we have WHEN, we
2013/9/23 Andres Freund
> On 2013-09-23 11:00:50 +0200, Marko Tiikkaja wrote:
> > On 9/23/13 10:50 AM, I wrote:
> > >On 9/23/13 6:40 AM, Pavel Stehule wrote:
> > >>After days I am thinking so it can be a good solution
> > >>
> > >>syntax - enhanced current RAISE
> > >>
> > >>RAISE ASSERT WHEN boo
2013/9/23 Marko Tiikkaja
> On 9/23/13 10:50 AM, I wrote:
>
>> On 9/23/13 6:40 AM, Pavel Stehule wrote:
>>
>>> After days I am thinking so it can be a good solution
>>>
>>> syntax - enhanced current RAISE
>>>
>>> RAISE ASSERT WHEN boolean expression
>>>
>>> RAISE ASSERT 'some message' WHEN express
2013/9/23 Amit Khandekar
>
>
>
> On 23 September 2013 10:10, Pavel Stehule wrote:
>
>>
>>
>>
>> 2013/9/22 Jaime Casanova
>>
>>>
>>> El 21/09/2013 17:16, "Jaime Casanova" escribió:
>>>
>>> >
>>> > On Fri, Sep 20, 2013 at 5:17 AM, Marko Tiikkaja wrote:
>>> > > On 9/20/13 12:09 PM, Amit Khandeka
On 2013-09-23 11:00:50 +0200, Marko Tiikkaja wrote:
> On 9/23/13 10:50 AM, I wrote:
> >On 9/23/13 6:40 AM, Pavel Stehule wrote:
> >>After days I am thinking so it can be a good solution
> >>
> >>syntax - enhanced current RAISE
> >>
> >>RAISE ASSERT WHEN boolean expression
> >>
> >>RAISE ASSERT 'som
On 23 September 2013 10:10, Pavel Stehule wrote:
>
>
>
> 2013/9/22 Jaime Casanova
>
>>
>> El 21/09/2013 17:16, "Jaime Casanova" escribió:
>>
>> >
>> > On Fri, Sep 20, 2013 at 5:17 AM, Marko Tiikkaja wrote:
>> > > On 9/20/13 12:09 PM, Amit Khandekar wrote:
>> > >>
>> > >> On 16 September 2013 0
On 9/23/13 10:50 AM, I wrote:
On 9/23/13 6:40 AM, Pavel Stehule wrote:
After days I am thinking so it can be a good solution
syntax - enhanced current RAISE
RAISE ASSERT WHEN boolean expression
RAISE ASSERT 'some message' WHEN expression
It looks like I'm losing this battle, but this syntax
2013/9/23 Marko Tiikkaja
> On 9/23/13 6:40 AM, Pavel Stehule wrote:
>
>> After days I am thinking so it can be a good solution
>>
>> syntax - enhanced current RAISE
>>
>> RAISE ASSERT WHEN boolean expression
>>
>> RAISE ASSERT 'some message' WHEN expression
>>
>
> It looks like I'm losing this ba
On 9/23/13 6:40 AM, Pavel Stehule wrote:
After days I am thinking so it can be a good solution
syntax - enhanced current RAISE
RAISE ASSERT WHEN boolean expression
RAISE ASSERT 'some message' WHEN expression
It looks like I'm losing this battle, but this syntax isn't too bad.
and we can ha
2013/9/22 Jaime Casanova
>
> El 21/09/2013 17:16, "Jaime Casanova" escribió:
>
> >
> > On Fri, Sep 20, 2013 at 5:17 AM, Marko Tiikkaja wrote:
> > > On 9/20/13 12:09 PM, Amit Khandekar wrote:
> > >>
> > >> On 16 September 2013 03:43, Marko Tiikkaja wrote:
> > >>>
> > >>> I think it would be ext
El 21/09/2013 17:16, "Jaime Casanova" escribió:
>
> On Fri, Sep 20, 2013 at 5:17 AM, Marko Tiikkaja wrote:
> > On 9/20/13 12:09 PM, Amit Khandekar wrote:
> >>
> >> On 16 September 2013 03:43, Marko Tiikkaja wrote:
> >>>
> >>> I think it would be extremely surprising if a command like that got
>
On Fri, Sep 20, 2013 at 5:17 AM, Marko Tiikkaja wrote:
> On 9/20/13 12:09 PM, Amit Khandekar wrote:
>>
>> On 16 September 2013 03:43, Marko Tiikkaja wrote:
>>>
>>> I think it would be extremely surprising if a command like that got
>>> optimized away based on a GUC, so I don't think that would be
On 9/19/13 7:08 AM, Pavel Stehule wrote:
FWIW, we've written a framework (currently available in the EnovaTools
project on pgFoundry) that allows for very, very fine-grain control over
asserts.
- Every assert has a name (and an optional sub-name) as well as a level
- You can global
2013/9/20 Alvaro Herrera
> Pavel Stehule escribió:
>
> > PL/pgSQL had a ADA completeness, uniformity and beauty newer. But it is
> not
> > too bad, and one new specialized statement doesn't kill us. A proposed
> > functionality is often used and we have not tools (macros) how to
> implement
> > i
Pavel Stehule escribió:
> PL/pgSQL had a ADA completeness, uniformity and beauty newer. But it is not
> too bad, and one new specialized statement doesn't kill us. A proposed
> functionality is often used and we have not tools (macros) how to implement
> it simply.
>
> we support a conditions for
On 09/20/2013 01:59 PM, Robert Haas wrote:
> The other part of the problem is that the language isn't designed from
> the beginning to be extensible. In Perl, for example, they chose to
> mark variables with a leading $, @, or % and functions with a leading
> &. That last marking has largely fall
2013/9/20 Robert Haas
> On Fri, Sep 20, 2013 at 6:24 AM, Marko Tiikkaja wrote:
> >> The issue of how this is spelled is somewhat secondary for me. I
> >> think ASSERT is probably as good as anything. But let's not kid
> >> ourselves: even reserving this word only in PL/pgsql WILL break things
On Fri, Sep 20, 2013 at 6:24 AM, Marko Tiikkaja wrote:
>> The issue of how this is spelled is somewhat secondary for me. I
>> think ASSERT is probably as good as anything. But let's not kid
>> ourselves: even reserving this word only in PL/pgsql WILL break things
>> for some users, and there are
On 9/19/13 9:09 PM, Robert Haas wrote:
Personally, I'm pretty skeptical about the value of adding dedicated
syntax for this. I mean, I'll be the first to admit that PL/pgsql is
a clunky and awkward language. But somebody's always proposing
something that they think will make it better, and I fe
On 9/20/13 12:09 PM, Amit Khandekar wrote:
On 16 September 2013 03:43, Marko Tiikkaja wrote:
I think it would be extremely surprising if a command like that got
optimized away based on a GUC, so I don't think that would be a good idea.
In pl_gram.y, in the rule stmt_raise, determine that thi
On 16 September 2013 03:43, Marko Tiikkaja wrote:
> On 2013-09-15 23:23, Jaime Casanova wrote:
>
>> If using ASSERT as keyword is not acceptable, not that i agree but in
>> case.
>> What about using RAISE EXCEPTION WHEN (condition)
>>
>
> I was going to suggest the same idea: Extend RAISE syntax
On Sat, Sep 14, 2013 at 6:09 PM, Marko Tiikkaja wrote:
> On 2013-09-14 23:55, Pavel Stehule wrote:
>> but introduction a reserved keword for one very special purpose (without
>> extensibility) is not prudent.
>
> How about using an existing keyword then? ASSERTION used to be reserved in
> the SQL
2013/9/19 Marko Tiikkaja
> On 9/19/13 2:08 PM, Pavel Stehule wrote:
>
>> I think so similar frameworks will be exists (we have some similar
>> Probably You and me have a same opinion so only simple and very primitive
>> assert is not enough:
>>
>> I see as useful feature for assertions:
>>
>> a)
On 9/19/13 2:08 PM, Pavel Stehule wrote:
I think so similar frameworks will be exists (we have some similar
Probably You and me have a same opinion so only simple and very primitive
assert is not enough:
I see as useful feature for assertions:
a) possibility to specify a message (two parametric
On 9/18/13 5:11 PM, Pavel Stehule wrote:
In this code a assert fail can be lost in app log. Or can be knowingly
handled and ignored - what is wrong, and should not be allowed.
When I wrote a little bit complex procedures, I had to use a EXCEPTION WHEN
OTHERS clause - because I would not to lost
2013/9/18 Jim Nasby
> On 9/14/13 11:55 PM, Pavel Stehule wrote:
>
>>
>>
>>
>> 2013/9/15 Marko Tiikkaja mailto:ma...@joh.to>>
>>
>>
>> On 2013-09-15 00:09, Pavel Stehule wrote:
>>
>> this is a possibility for introduction a new hook and possibility
>> implement
>> asserions and
On 9/14/13 11:55 PM, Pavel Stehule wrote:
2013/9/15 Marko Tiikkaja mailto:ma...@joh.to>>
On 2013-09-15 00:09, Pavel Stehule wrote:
this is a possibility for introduction a new hook and possibility
implement
asserions and similar task in generic form (as extension). it ca
Hello
2013/9/18 Marko Tiikkaja
> On 2013-09-16 21:24, Pavel Stehule wrote:
>
>> 2. a failed assert should to raise a exception, that should not be handled
>> by any exception handler - similar to ERRCODE_QUERY_CANCELED - see
>> exception_matches_conditions.
>>
>
> I'm not sure what I think abou
On 2013-09-16 21:24, Pavel Stehule wrote:
2. a failed assert should to raise a exception, that should not be handled
by any exception handler - similar to ERRCODE_QUERY_CANCELED - see
exception_matches_conditions.
I'm not sure what I think about that idea. I see decent arguments for
it workin
Hello
a few other comments:
1. you disable a assert in compile time in dependency of enable_assertions
variable. I don't think, so it is good idea. When somebody enables a
assertions, then assertions will not work on all cached functions in
session. You should to do check if assertions are enable
On 9/15/13 10:49 AM, Marko Tiikkaja wrote:
> On 2013-09-15 16:34, Peter Eisentraut wrote:
>> On Sat, 2013-09-14 at 20:47 +0200, Marko Tiikkaja wrote:
>>> Attached is a patch for supporting assertions in PL/PgSQL. These are
>>> similar to the Assert() backend macro: they can be disabled during
>>>
El 15/09/2013 17:13, "Marko Tiikkaja" escribió:
>
> On 2013-09-15 23:23, Jaime Casanova wrote:
>>
>> If using ASSERT as keyword is not acceptable, not that i agree but in
case.
>> What about using RAISE EXCEPTION WHEN (condition)
>
>
> I think it would be extremely surprising if a command like tha
On 2013-09-15 23:23, Jaime Casanova wrote:
If using ASSERT as keyword is not acceptable, not that i agree but in case.
What about using RAISE EXCEPTION WHEN (condition)
I think it would be extremely surprising if a command like that got
optimized away based on a GUC, so I don't think that woul
El 14/09/2013 15:25, "Pavel Stehule" escribió:
>
> Hello
>
> There is a significant issue - new reserved keyword. There is high
probability so lot of users has a functions named "assert".
>
> I like this functionality, but I dislike any compatibility break for
feature, that can be implemented as e
On 2013-09-15 16:34, Peter Eisentraut wrote:
On Sat, 2013-09-14 at 20:47 +0200, Marko Tiikkaja wrote:
Attached is a patch for supporting assertions in PL/PgSQL. These are
similar to the Assert() backend macro: they can be disabled during
compile time, but when enabled, abort execution if the pa
On Sat, 2013-09-14 at 20:47 +0200, Marko Tiikkaja wrote:
> Attached is a patch for supporting assertions in PL/PgSQL. These are
> similar to the Assert() backend macro: they can be disabled during
> compile time, but when enabled, abort execution if the passed expression
> is not true.
Doesn't
2013/9/15 Marko Tiikkaja
> On 2013-09-15 00:09, Pavel Stehule wrote:
>
>> this is a possibility for introduction a new hook and possibility
>> implement
>> asserions and similar task in generic form (as extension). it can be
>> assertions, tracing, profiling.
>>
>
> You can already do tracing and
On 2013-09-15 00:09, Pavel Stehule wrote:
this is a possibility for introduction a new hook and possibility implement
asserions and similar task in generic form (as extension). it can be
assertions, tracing, profiling.
You can already do tracing and profiling in an extension. I don't see
what
On 2013-09-14 23:55, Pavel Stehule wrote:
but introduction a reserved keword for one very special purpose (without
extensibility) is not prudent.
How about using an existing keyword then? ASSERTION used to be reserved
in the SQL standard but is unreserved in postgres. CHECK might work and
i
Dne 14. 9. 2013 23:55 "Pavel Stehule" napsal(a):
>
>
> Dne 14. 9. 2013 23:35 "Marko Tiikkaja" napsal(a):
>
> >
> > On 2013-09-14 23:05, Pavel Stehule wrote:
> >>
> >> A some languages has a generic PRAGMA keyword. So I would be much more
> >> happy with something like
> >>
> >> PRAGMA Assert(foun
Dne 14. 9. 2013 23:35 "Marko Tiikkaja" napsal(a):
>
> On 2013-09-14 23:05, Pavel Stehule wrote:
>>
>> A some languages has a generic PRAGMA keyword. So I would be much more
>> happy with something like
>>
>> PRAGMA Assert(found);
>>
>> It is much more close to ADA, and it allows a reuse of new key
On 2013-09-14 23:05, Pavel Stehule wrote:
A some languages has a generic PRAGMA keyword. So I would be much more
happy with something like
PRAGMA Assert(found);
It is much more close to ADA, and it allows a reuse of new keyword for any
other usage in future (your proposal is too simply, without
2013/9/14 Marko Tiikkaja
> On 2013-09-14 22:40, I wrote:
>
>> Someone may prove me wrong here, but to me it looks like this would only
>> prevent ASSERT from being used as the name of a PL/PgSQL variable.
>>
>
> The comment at the beginning of pl_scanner.c seems to suggest same.
>
yes, there are
On 2013-09-14 22:40, I wrote:
Someone may prove me wrong here, but to me it looks like this would only
prevent ASSERT from being used as the name of a PL/PgSQL variable.
The comment at the beginning of pl_scanner.c seems to suggest same.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mai
On 2013-09-14 22:24, Pavel Stehule wrote:
There is a significant issue - new reserved keyword. There is high
probability so lot of users has a functions named "assert".
Someone may prove me wrong here, but to me it looks like this would only
prevent ASSERT from being used as the name of a PL/P
El 14/09/2013 15:18, "Marko Tiikkaja" escribió:
>
> On 2013-09-14 21:55, Jaime Casanova wrote:
>>
>> On Sat, Sep 14, 2013 at 1:52 PM, Marko Tiikkaja wrote:
>>>
>>> And by "compile time" here, I mean at the time when the PL/PgSQL
function
>>
>> is
>>>
>>> compiled, not the postgres server binary.
Hello
There is a significant issue - new reserved keyword. There is high
probability so lot of users has a functions named "assert".
I like this functionality, but I dislike any compatibility break for
feature, that can be implemented as extension without any lost of
compatibility or lost of func
On 2013-09-14 21:55, Jaime Casanova wrote:
On Sat, Sep 14, 2013 at 1:52 PM, Marko Tiikkaja wrote:
And by "compile time" here, I mean at the time when the PL/PgSQL function
is
compiled, not the postgres server binary.
and "compile time" means when the function is created or replaced? or the
On Sat, Sep 14, 2013 at 1:52 PM, Marko Tiikkaja wrote:
> On 14/09/2013 20:47, I wrote:
>>
>> These are
>> similar to the Assert() backend macro: they can be disabled during
>> compile time, but when enabled, abort execution if the passed expression
>> is not true.
>
Hi,
That's very good, thanks.
On 14/09/2013 20:47, I wrote:
These are
similar to the Assert() backend macro: they can be disabled during
compile time, but when enabled, abort execution if the passed expression
is not true.
And by "compile time" here, I mean at the time when the PL/PgSQL
function is compiled, not the postgr
Hi,
Attached is a patch for supporting assertions in PL/PgSQL. These are
similar to the Assert() backend macro: they can be disabled during
compile time, but when enabled, abort execution if the passed expression
is not true.
A simple example:
CREATE FUNCTION delete_user(username text) RET
67 matches
Mail list logo
