2015-03-25 0:17 GMT+01:00 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
updated version with Jim Nasby's doc and rebase against last changes in
plpgsql.
I started looking at this patch. ISTM there are some pretty questionable
design decisions in it:
1. Why
On 3/25/15 1:21 AM, Pavel Stehule wrote:
2015-03-25 0:17 GMT+01:00 Tom Lane t...@sss.pgh.pa.us
mailto:t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com
mailto:pavel.steh...@gmail.com writes:
updated version with Jim Nasby's doc and rebase against last changes in
Jim Nasby jim.na...@bluetreble.com writes:
On 3/25/15 1:21 AM, Pavel Stehule wrote:
2015-03-25 0:17 GMT+01:00 Tom Lane t...@sss.pgh.pa.us
mailto:t...@sss.pgh.pa.us:
(BTW, is considering
NULL to be a failure the right thing? SQL CHECK conditions consider
NULL to be allowed ...)
This is a
2015-03-26 0:08 GMT+01:00 Tom Lane t...@sss.pgh.pa.us:
Jim Nasby jim.na...@bluetreble.com writes:
On 3/25/15 1:21 AM, Pavel Stehule wrote:
2015-03-25 0:17 GMT+01:00 Tom Lane t...@sss.pgh.pa.us
mailto:t...@sss.pgh.pa.us:
(BTW, is considering
NULL to be a failure the right thing? SQL
Pavel Stehule pavel.steh...@gmail.com writes:
updated version with Jim Nasby's doc and rebase against last changes in
plpgsql.
I started looking at this patch. ISTM there are some pretty questionable
design decisions in it:
1. Why create a core GUC to control a behavior that's plpgsql-only?
I
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
Note that pgcrypto is failing 3 tests, same as in master.
The new
2015-01-28 0:13 GMT+01:00 Jim Nasby jim.na...@bluetreble.com:
On 1/27/15 1:30 PM, Pavel Stehule wrote:
I don't see the separate warning as being helpful. I'd just do
something like
+(err_hint != NULL) ? errhint(%s,
err_hint) : errhint(Message
2015-01-26 22:34 GMT+01:00 Jim Nasby jim.na...@bluetreble.com:
On 1/22/15 2:01 PM, Pavel Stehule wrote:
* I would to simplify a behave of evaluating of message
expression - probably I disallow NULL there.
Well, the only thing I could see you doing there is throwing a
On 1/27/15 1:30 PM, Pavel Stehule wrote:
I don't see the separate warning as being helpful. I'd just do something
like
+(err_hint != NULL) ? errhint(%s, err_hint) :
errhint(Message attached to failed assertion is null) ));
done
There should also
2015-01-28 0:13 GMT+01:00 Jim Nasby jim.na...@bluetreble.com:
On 1/27/15 1:30 PM, Pavel Stehule wrote:
I don't see the separate warning as being helpful. I'd just do
something like
+(err_hint != NULL) ? errhint(%s,
err_hint) : errhint(Message
2015-01-26 22:34 GMT+01:00 Jim Nasby jim.na...@bluetreble.com:
On 1/22/15 2:01 PM, Pavel Stehule wrote:
* I would to simplify a behave of evaluating of message
expression - probably I disallow NULL there.
Well, the only thing I could see you doing there is throwing a
On 1/22/15 2:01 PM, Pavel Stehule wrote:
* I would to simplify a behave of evaluating of message expression -
probably I disallow NULL there.
Well, the only thing I could see you doing there is throwing a different
error if the hint is null. I don't see that as an improvement.
Hi
here is updated patch
2015-01-21 23:28 GMT+01:00 Jim Nasby jim.na...@bluetreble.com:
On 1/21/15 3:10 PM, Pavel Stehule wrote:
is there some agreement on this behave of ASSERT statement?
I would to assign last patch to next commitfest.
Possible changes:
* I would to simplify a
Hi all
is there some agreement on this behave of ASSERT statement?
I would to assign last patch to next commitfest.
Possible changes:
* I would to simplify a behave of evaluating of message expression -
probably I disallow NULL there.
* GUC enable_asserts will be supported
* a assert exception
Hi
any comments to last proposal and patch?
Pavel
2014-11-26 19:52 GMT+01:00 Pavel Stehule pavel.steh...@gmail.com:
Hi
2014-11-26 16:46 GMT+01:00 Pavel Stehule pavel.steh...@gmail.com:
2014-11-26 13:31 GMT+01:00 Marko Tiikkaja ma...@joh.to:
On 11/26/14 8:55 AM, Pavel Stehule wrote:
Pavel Stehule wrote:
Hi
any comments to last proposal and patch?
WTH is that pstrdup(hint is null) thing? Debugging leftover?
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training Services
--
Sent via pgsql-hackers
2014-12-14 18:57 GMT+01:00 Alvaro Herrera alvhe...@2ndquadrant.com:
Pavel Stehule wrote:
Hi
any comments to last proposal and patch?
WTH is that pstrdup(hint is null) thing? Debugging leftover?
No, only not well error message. I propose a syntax ASSERT
boolean_expression [, text
On 11/26/14 8:55 AM, Pavel Stehule wrote:
* should be assertions globally enabled/disabled? - I have no personal
preference in this question.
I think so. The way I would use this function is to put expensive
checks into strategic locations which would only run when developing
locally (and
2014-11-26 13:31 GMT+01:00 Marko Tiikkaja ma...@joh.to:
On 11/26/14 8:55 AM, Pavel Stehule wrote:
* should be assertions globally enabled/disabled? - I have no personal
preference in this question.
I think so. The way I would use this function is to put expensive checks
into strategic
Hi
2014-11-26 16:46 GMT+01:00 Pavel Stehule pavel.steh...@gmail.com:
2014-11-26 13:31 GMT+01:00 Marko Tiikkaja ma...@joh.to:
On 11/26/14 8:55 AM, Pavel Stehule wrote:
* should be assertions globally enabled/disabled? - I have no personal
preference in this question.
I think so. The
Hi all
so one problem is closed, and we can start speaking about ASSERT statement.
I propose a (old) syntax
ASSERT expr [, message]
possible questions:
* should be assertions globally enabled/disabled? - I have no personal
preference in this question.
* can be ASSERT exception handled ? - I
On Sun, Nov 23, 2014 at 4:40 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
The core of that complaint is that we'd have to make ASSERT a plpgsql
reserved word, which is true enough as things stand today. However,
why is it that plpgsql statement-introducing keywords need to be
reserved?
Robert Haas robertmh...@gmail.com writes:
On Sun, Nov 23, 2014 at 4:40 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Attached is a draft patch that de-reserves 17 of plpgsql's existing
reserved words, leaving 24 still reserved (of which only 9 are not also
reserved in the core grammar). This would
On Mon, Nov 24, 2014 at 2:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Two comments on that:
1. What is the likely use-case for such a thing (considering SQL is not
exactly friendly to pointers or reference types),
I happen to know that Oracle supports more possible LHS syntaxes in
PL/SQL than
I wrote:
The core of that complaint is that we'd have to make ASSERT a plpgsql
reserved word, which is true enough as things stand today. However,
why is it that plpgsql statement-introducing keywords need to be
reserved? The only reason for that AFAICS is to allow us to distinguish
the
On 19 November 2014 23:29, Tom Lane t...@sss.pgh.pa.us wrote:
Pavel Stehule pavel.steh...@gmail.com writes:
2014-11-19 23:54 GMT+01:00 Tom Lane t...@sss.pgh.pa.us:
The core of that complaint is that we'd have to make ASSERT a plpgsql
reserved word, which is true enough as things stand today.
On 18 November 2014 21:19, Petr Jelinek p...@2ndquadrant.com wrote:
Personally, I see this as natural extension of the conditional block control
which we already have for loops with CONTINUE WHEN and EXIT WHEN. This
basically extends it to any block and it seems quite natural to have it for
On 11/19/2014 06:35 AM, Simon Riggs wrote:
On 18 November 2014 21:19, Petr Jelinek p...@2ndquadrant.com wrote:
Personally, I see this as natural extension of the conditional block control
which we already have for loops with CONTINUE WHEN and EXIT WHEN. This
basically extends it to any block
On 18 November 2014 21:19, Petr Jelinek p...@2ndquadrant.com wrote:
Personally, I see this as natural extension of the conditional block
control
which we already have for loops with CONTINUE WHEN and EXIT WHEN. This
basically extends it to any block and it seems quite natural to have it
Andrew Dunstan and...@dunslane.net writes:
On 11/19/2014 06:35 AM, Simon Riggs wrote:
I seem to share the same opinion with Andrew: its not going to hurt to
include this, but its not gonna cause dancing in the streets either. I
would characterize that as 2 very neutral and unimpressed people,
On Wed, Nov 19, 2014 at 11:13 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
On 11/19/2014 06:35 AM, Simon Riggs wrote:
I seem to share the same opinion with Andrew: its not going to hurt to
include this, but its not gonna cause dancing in the streets either.
On Wed, Nov 19, 2014 at 12:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Nov 19, 2014 at 11:13 AM, Tom Lane t...@sss.pgh.pa.us wrote:
FWIW, I would vote against it also. I do not find this to be a natural
extension of RAISE; it adds all sorts of
2014-11-19 17:13 GMT+01:00 Tom Lane t...@sss.pgh.pa.us:
Andrew Dunstan and...@dunslane.net writes:
On 11/19/2014 06:35 AM, Simon Riggs wrote:
I seem to share the same opinion with Andrew: its not going to hurt to
include this, but its not gonna cause dancing in the streets either. I
2014-11-19 17:43 GMT+01:00 Robert Haas robertmh...@gmail.com:
On Wed, Nov 19, 2014 at 11:13 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
On 11/19/2014 06:35 AM, Simon Riggs wrote:
I seem to share the same opinion with Andrew: its not going to hurt to
2014-11-19 18:01 GMT+01:00 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
On Wed, Nov 19, 2014 at 11:13 AM, Tom Lane t...@sss.pgh.pa.us wrote:
FWIW, I would vote against it also. I do not find this to be a natural
extension of RAISE; it adds all sorts of semantic
On 2014-11-19 23:18, Pavel Stehule wrote:
2014-11-19 18:01 GMT+01:00 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
On Wed, Nov 19, 2014 at 11:13 AM, Tom Lane t...@sss.pgh.pa.us wrote:
FWIW, I would vote against it also. I do not find this to be a natural
extension
Marko Tiikkaja ma...@joh.to writes:
I also went back to the original thread, and I think Heikki's summary
dismissed e.g. Robert's criticism quite lightly:
http://www.postgresql.org/message-id/ca+tgmobwossrncv_ijk3xhsytxb7dv0awgvwkmeurntovez...@mail.gmail.com
The core of that complaint is
2014-11-19 23:38 GMT+01:00 Marko Tiikkaja ma...@joh.to:
On 2014-11-19 23:18, Pavel Stehule wrote:
2014-11-19 18:01 GMT+01:00 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
On Wed, Nov 19, 2014 at 11:13 AM, Tom Lane t...@sss.pgh.pa.us wrote:
FWIW, I would vote
2014-11-19 23:54 GMT+01:00 Tom Lane t...@sss.pgh.pa.us:
Marko Tiikkaja ma...@joh.to writes:
I also went back to the original thread, and I think Heikki's summary
dismissed e.g. Robert's criticism quite lightly:
Pavel Stehule pavel.steh...@gmail.com writes:
2014-11-19 23:54 GMT+01:00 Tom Lane t...@sss.pgh.pa.us:
The core of that complaint is that we'd have to make ASSERT a plpgsql
reserved word, which is true enough as things stand today. However,
why is it that plpgsql statement-introducing keywords
On 18 November 2014 01:00, Jim Nasby jim.na...@bluetreble.com wrote:
On 11/17/14, 4:58 PM, Simon Riggs wrote:
Great, looks good to me, marking as ready for committer.
What is wrong with using IF ?
It's a hell of a lot wordier. I've previously created a more sophisticated
assert framework
2014-11-18 10:23 GMT+01:00 Simon Riggs si...@2ndquadrant.com:
On 18 November 2014 01:00, Jim Nasby jim.na...@bluetreble.com wrote:
On 11/17/14, 4:58 PM, Simon Riggs wrote:
Great, looks good to me, marking as ready for committer.
What is wrong with using IF ?
It's a hell of a
On 11/18/2014 04:23 AM, Simon Riggs wrote:
On 18 November 2014 01:00, Jim Nasby jim.na...@bluetreble.com wrote:
On 11/17/14, 4:58 PM, Simon Riggs wrote:
Great, looks good to me, marking as ready for committer.
What is wrong with using IF ?
It's a hell of a lot wordier. I've previously
2014-11-18 17:08 GMT+01:00 Simon Riggs si...@2ndquadrant.com:
On 18 November 2014 12:29, Pavel Stehule pavel.steh...@gmail.com wrote:
Why is that not a requirement for a less wordier form of IF?
IF (something) THEN action
statement IF is a control statement - and syntax, pattern for
On 11/18/14, 9:31 AM, Andrew Dunstan wrote:
Frankly, I find this whole proposal, and all the suggested alternatives,
somewhat ill-conceived. PLPGSQL is a wordy language. If you want something more
terse, use something else. Adding these sorts of syntactic sugar warts onto the
language
On 11/18/2014 02:53 PM, Jim Nasby wrote:
On 11/18/14, 9:31 AM, Andrew Dunstan wrote:
Frankly, I find this whole proposal, and all the suggested
alternatives, somewhat ill-conceived. PLPGSQL is a wordy language. If
you want something more terse, use something else. Adding these sorts
of
2014-11-18 21:27 GMT+01:00 Andrew Dunstan and...@dunslane.net:
On 11/18/2014 02:53 PM, Jim Nasby wrote:
On 11/18/14, 9:31 AM, Andrew Dunstan wrote:
Frankly, I find this whole proposal, and all the suggested alternatives,
somewhat ill-conceived. PLPGSQL is a wordy language. If you want
On 18/11/14 22:11, Pavel Stehule wrote:
2014-11-18 21:27 GMT+01:00 Andrew Dunstan and...@dunslane.net
mailto:and...@dunslane.net:
I frequently write one-statement bodies of IF statements. To me
that's not a big deal either :-)
anybody did it, but it doesn't need so it is perfect :)
On 11/18/2014 04:11 PM, Pavel Stehule wrote:
2014-11-18 21:27 GMT+01:00 Andrew Dunstan and...@dunslane.net
mailto:and...@dunslane.net:
On 11/18/2014 02:53 PM, Jim Nasby wrote:
On 11/18/14, 9:31 AM, Andrew Dunstan wrote:
Frankly, I find this whole proposal, and
2014-11-18 22:28 GMT+01:00 Andrew Dunstan and...@dunslane.net:
On 11/18/2014 04:11 PM, Pavel Stehule wrote:
2014-11-18 21:27 GMT+01:00 Andrew Dunstan and...@dunslane.net mailto:
and...@dunslane.net:
On 11/18/2014 02:53 PM, Jim Nasby wrote:
On 11/18/14, 9:31 AM, Andrew
Great, looks good to me, marking as ready for committer.
What is wrong with using IF ?
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On 11/17/14, 4:58 PM, Simon Riggs wrote:
Great, looks good to me, marking as ready for committer.
What is wrong with using IF ?
It's a hell of a lot wordier. I've previously created a more sophisticated
assert framework to allow more control over things, but ended up also using
it just for
2014-11-17 23:58 GMT+01:00 Simon Riggs si...@2ndquadrant.com:
Great, looks good to me, marking as ready for committer.
What is wrong with using IF ?
It significantly increase code' length .. and decrease readability when you
intensive use a pattern IF THEN RAISE END IF - when you check
On 16/10/14 13:29, Pavel Stehule wrote:
Hi
2014-10-14 22:57 GMT+02:00 Petr Jelinek p...@2ndquadrant.com
Short review of the patch. Note that this has nothing to do with
actual assertions, at the moment it's just enhancement of RAISE
statement to make it optionally conditional. As I
2014-10-17 9:14 GMT+02:00 Petr Jelinek p...@2ndquadrant.com:
On 16/10/14 13:29, Pavel Stehule wrote:
Hi
2014-10-14 22:57 GMT+02:00 Petr Jelinek p...@2ndquadrant.com
Short review of the patch. Note that this has nothing to do with
actual assertions, at the moment it's just
2014-10-15 11:57 GMT+02:00 Ali Akbar the.ap...@gmail.com:
2014-09-30 10:04 GMT+07:00 Jim Nasby j...@nasby.net:
On 9/17/14, 7:40 PM, Jan Wieck wrote:
Exactly. Doing something like
ASSERT (select count(*) from foo
where fk not in (select pk from bar)) = 0;
is a perfectly
Hi
2014-10-14 22:57 GMT+02:00 Petr Jelinek p...@2ndquadrant.com:
On 09/09/14 17:37, Pavel Stehule wrote:
Ada is language with strong character, and PLpgSQL is little bit strange
fork - so it isn't easy to find some form, how to solve all requirements.
My requests:
* be consistent with
2014-09-30 10:04 GMT+07:00 Jim Nasby j...@nasby.net:
On 9/17/14, 7:40 PM, Jan Wieck wrote:
Exactly. Doing something like
ASSERT (select count(*) from foo
where fk not in (select pk from bar)) = 0;
is a perfectly fine, arbitrary boolean expression. It will probably work
well
On 09/09/14 17:37, Pavel Stehule wrote:
Ada is language with strong character, and PLpgSQL is little bit strange
fork - so it isn't easy to find some form, how to solve all requirements.
My requests:
* be consistent with current PLpgSQL syntax and logic
* allow some future extensibility
*
On 9/16/14 12:01 AM, Alvaro Herrera wrote:
Jan Wieck wrote:
I think that most data integrity issues can be handled by a well
designed database schema that uses UNIQUE, NOT NULL, REFERENCES and
CHECK constraints. Assertions are usually found inside of complex
code constructs to check values of
On 9/14/14 2:49 PM, Jan Wieck wrote:
I don't think it is even a good idea to implement assertions that can
query arbitrary data.
In a normal programming language, an assertion is usually a static fault
in your program. If the assertion ever fails, you fix your program and
then it hopefully
On 9/17/14, 9:00 PM, Peter Eisentraut wrote:
On 9/14/14 2:49 PM, Jan Wieck wrote:
I don't think it is even a good idea to implement assertions that can
query arbitrary data.
In a normal programming language, an assertion is usually a static fault
in your program. If the assertion ever fails,
2014-09-17 21:00 GMT+02:00 Peter Eisentraut pete...@gmx.net:
On 9/14/14 2:49 PM, Jan Wieck wrote:
I don't think it is even a good idea to implement assertions that can
query arbitrary data.
In a normal programming language, an assertion is usually a static fault
in your program. If the
On 9/17/14 3:04 PM, Pavel Stehule wrote:
What is difference between content of variable or content of database?
You can test any prerequisite, but when this prerequisite is not solved,
than exception is very very hard without possible handling.
If the assertion tests arbitrary Boolean
2014-09-17 21:36 GMT+02:00 Peter Eisentraut pete...@gmx.net:
On 9/17/14 3:04 PM, Pavel Stehule wrote:
What is difference between content of variable or content of database?
You can test any prerequisite, but when this prerequisite is not solved,
than exception is very very hard without
On 09/17/2014 03:36 PM, Peter Eisentraut wrote:
On 9/17/14 3:04 PM, Pavel Stehule wrote:
What is difference between content of variable or content of database?
You can test any prerequisite, but when this prerequisite is not solved,
than exception is very very hard without possible handling.
Jan Wieck wrote:
On 09/14/2014 02:25 PM, Pavel Stehule wrote:
a) Isn't possible handle a assertion exception anywhere .. it enforce
ROLLBACK in 100%
b) Assertions should be disabled globally .. I am not sure, it it is a
good idea, but I can understand so some tests based on queries to data
2014-09-09 7:54 GMT+02:00 Craig Ringer cr...@2ndquadrant.com:
On 09/05/2014 05:21 PM, Pavel Stehule wrote:
*shrug* Doing it in SQL would probably break more stuff. I'm trying to
contain the damage. And arguably, this is mostly only useful in
PL/PgSQL.
I've wanted assertions in SQL
On 09/14/2014 02:25 PM, Pavel Stehule wrote:
a) Isn't possible handle a assertion exception anywhere .. it enforce
ROLLBACK in 100%
b) Assertions should be disabled globally .. I am not sure, it it is a
good idea, but I can understand so some tests based on queries to data
can be performance
On 2014-09-09 07:54, Craig Ringer wrote:
On 09/05/2014 05:21 PM, Pavel Stehule wrote:
*shrug* Doing it in SQL would probably break more stuff. I'm trying to
contain the damage. And arguably, this is mostly only useful in PL/PgSQL.
I've wanted assertions in SQL enough that I often write
2014-09-09 7:55 GMT+02:00 Craig Ringer cr...@2ndquadrant.com:
On 09/09/2014 05:20 AM, Robert Haas wrote:
I previously proposed RAISE ASSERT ... WHERE, which seems like a nice
variant of what we've already got, but perhaps this whole discussion
merely illustrates that it's hard to get
On Fri, Sep 5, 2014 at 2:16 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
Assert is usually implemented as custom functions and used via PERFORM
statement now
-- usual current solution
PERFORM Assert(some expression)
I would to implement Assert as plpgsql internal statement due bigger
On 09/05/2014 05:21 PM, Pavel Stehule wrote:
*shrug* Doing it in SQL would probably break more stuff. I'm trying to
contain the damage. And arguably, this is mostly only useful in PL/PgSQL.
I've wanted assertions in SQL enough that I often write trivial wrappers
around `raise` in PL/PgSQL
On 09/09/2014 05:20 AM, Robert Haas wrote:
I previously proposed RAISE ASSERT ... WHERE, which seems like a nice
variant of what we've already got, but perhaps this whole discussion
merely illustrates that it's hard to get more than 1 vote for any
proposal in this area.
Well, you have
On 05/09/14 14:35, Jan Wieck wrote:
On 09/05/2014 04:40 AM, Pavel Stehule wrote:
Adding a WHEN clause to RAISE would have the benefit of not needing any
new keywords at all.
RAISE EXCEPTION 'format' [, expr ...] WHEN row_count 1;
+1
--
Petr Jelinek
On 2014-09-06 7:27 AM, Pavel Stehule wrote:
2014-09-05 14:35 GMT+02:00 Jan Wieck j...@wi3ck.info:
Adding a WHEN clause to RAISE would have the benefit of not needing any
new keywords at all.
RAISE EXCEPTION 'format' [, expr ...] WHEN row_count 1;
It was one my older proposal.
Can we find
2014-09-06 19:26 GMT+02:00 Marko Tiikkaja ma...@joh.to:
On 2014-09-06 7:27 AM, Pavel Stehule wrote:
2014-09-05 14:35 GMT+02:00 Jan Wieck j...@wi3ck.info:
Adding a WHEN clause to RAISE would have the benefit of not needing any
new keywords at all.
RAISE EXCEPTION 'format' [, expr ...] WHEN
On 2014-09-06 7:49 PM, Pavel Stehule wrote:
this doesn't to supply assertions, it is just shorter form
The original proposal very clearly seems to be why don't we do this
*instead* of assertions? And in that case all of my points apply, and
I'm very much against this syntax. If this is
2014-09-06 19:59 GMT+02:00 Marko Tiikkaja ma...@joh.to:
On 2014-09-06 7:49 PM, Pavel Stehule wrote:
this doesn't to supply assertions, it is just shorter form
The original proposal very clearly seems to be why don't we do this
*instead* of assertions? And in that case all of my points
Hello
Assert is usually implemented as custom functions and used via PERFORM
statement now
-- usual current solution
PERFORM Assert(some expression)
I would to implement Assert as plpgsql internal statement due bigger
possibilities to design syntax and internal implementation now and in
future.
On 2014-09-05 08:16, Pavel Stehule wrote:
Assert is usually implemented as custom functions and used via PERFORM
statement now
-- usual current solution
PERFORM Assert(some expression)
I would to implement Assert as plpgsql internal statement due bigger
possibilities to design syntax and
2014-09-05 9:52 GMT+02:00 Marko Tiikkaja ma...@joh.to:
On 2014-09-05 08:16, Pavel Stehule wrote:
Assert is usually implemented as custom functions and used via PERFORM
statement now
-- usual current solution
PERFORM Assert(some expression)
I would to implement Assert as plpgsql internal
On 9/5/14 10:09 AM, Pavel Stehule wrote:
I think this could still be parsed correctly, though I'm not 100% sure on
that:
ASSERT WARNING (EXISTS(SELECT ..)), 'data are there';
PLpgSQL uses a ';' or some plpgsql keyword as SQL statement delimiter. It
reason why RETURN QUERY ... ';' So in this
2014-09-05 10:33 GMT+02:00 Marko Tiikkaja ma...@joh.to:
On 9/5/14 10:09 AM, Pavel Stehule wrote:
I think this could still be parsed correctly, though I'm not 100% sure on
that:
ASSERT WARNING (EXISTS(SELECT ..)), 'data are there';
PLpgSQL uses a ';' or some plpgsql keyword as SQL
On 9/5/14 10:40 AM, Pavel Stehule wrote:
2014-09-05 10:33 GMT+02:00 Marko Tiikkaja ma...@joh.to:
I don't see why. The PL/PgSQL SQL parser goes to great lengths to
identify unmatched parenthesis. But the parens probably aren't necessary
in the first place; you could just omit them and keep
2014-09-05 10:57 GMT+02:00 Marko Tiikkaja ma...@joh.to:
On 9/5/14 10:40 AM, Pavel Stehule wrote:
2014-09-05 10:33 GMT+02:00 Marko Tiikkaja ma...@joh.to:
I don't see why. The PL/PgSQL SQL parser goes to great lengths to
identify unmatched parenthesis. But the parens probably aren't
On 9/5/14 11:08 AM, Pavel Stehule wrote:
2014-09-05 10:57 GMT+02:00 Marko Tiikkaja ma...@joh.to:
Oops. I meant to type ASSERT there, instead of RAISE. Does that make
more sense?
for me a basic limit is boolean_expr
I don't understand what you mean by this.
It is about semantic and
2014-09-05 11:17 GMT+02:00 Marko Tiikkaja ma...@joh.to:
On 9/5/14 11:08 AM, Pavel Stehule wrote:
2014-09-05 10:57 GMT+02:00 Marko Tiikkaja ma...@joh.to:
Oops. I meant to type ASSERT there, instead of RAISE. Does that make
more sense?
for me a basic limit is boolean_expr
I don't
On 09/05/2014 04:40 AM, Pavel Stehule wrote:
2014-09-05 10:33 GMT+02:00 Marko Tiikkaja ma...@joh.to
mailto:ma...@joh.to:
On 9/5/14 10:09 AM, Pavel Stehule wrote:
I think this could still be parsed correctly, though I'm not
100% sure on
that:
2014-09-05 14:35 GMT+02:00 Jan Wieck j...@wi3ck.info:
On 09/05/2014 04:40 AM, Pavel Stehule wrote:
2014-09-05 10:33 GMT+02:00 Marko Tiikkaja ma...@joh.to
mailto:ma...@joh.to:
On 9/5/14 10:09 AM, Pavel Stehule wrote:
I think this could still be parsed correctly, though
90 matches
Mail list logo
