Re: [HACKERS] proposal: plpgsql - Assert statement

2015-03-26 0:08 GMT+01:00 Tom Lane : > Jim Nasby writes: > > On 3/25/15 1:21 AM, Pavel Stehule wrote: > >> 2015-03-25 0:17 GMT+01:00 Tom Lane >> >: > >>> (BTW, is considering > >>> NULL to be a failure the right thing? SQL CHECK conditions consider > >>> NULL to be al

Re: [HACKERS] proposal: plpgsql - Assert statement

Jim Nasby writes: > On 3/25/15 1:21 AM, Pavel Stehule wrote: >> 2015-03-25 0:17 GMT+01:00 Tom Lane > >: >>> (BTW, is considering >>> NULL to be a failure the right thing? SQL CHECK conditions consider >>> NULL to be allowed ...) >> This is a question - I am happy with

Re: [HACKERS] proposal: plpgsql - Assert statement

On 3/25/15 1:21 AM, Pavel Stehule wrote: 2015-03-25 0:17 GMT+01:00 Tom Lane mailto:t...@sss.pgh.pa.us>>: Pavel Stehule mailto: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.

Re: [HACKERS] proposal: plpgsql - Assert statement

2015-03-25 0:17 GMT+01:00 Tom Lane : > Pavel Stehule 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 b

Re: [HACKERS] proposal: plpgsql - Assert statement

Pavel Stehule 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 think it'd make more

Re: [HACKERS] proposal: plpgsql - Assert statement

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 st

Re: [HACKERS] proposal: plpgsql - Assert statement

2015-01-28 0:13 GMT+01:00 Jim Nasby : > 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 faile

Re: [HACKERS] proposal: plpgsql - Assert statement

2015-01-28 0:13 GMT+01:00 Jim Nasby : > 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 faile

Re: [HACKERS] proposal: plpgsql - Assert statement

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 a

Re: [HACKERS] proposal: plpgsql - Assert statement

2015-01-26 22:34 GMT+01:00 Jim Nasby : > 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 i

Re: [HACKERS] proposal: plpgsql - Assert statement

2015-01-26 22:34 GMT+01:00 Jim Nasby : > 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 i

Re: [HACKERS] proposal: plpgsql - Assert statement

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. I'

Re: [HACKERS] proposal: plpgsql - Assert statement

Hi here is updated patch 2015-01-21 23:28 GMT+01:00 Jim Nasby : > 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 behave of ev

Re: [HACKERS] proposal: plpgsql - Assert statement

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 behave of evaluating of message expression - probably I disallow NULL there. Well, the only thing

Re: [HACKERS] proposal: plpgsql - Assert statement

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

Re: [HACKERS] proposal: plpgsql - Assert statement

2014-12-14 18:57 GMT+01:00 Alvaro Herrera : > > 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 expression ] -- t

Re: [HACKERS] proposal: plpgsql - Assert statement

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

Re: [HACKERS] proposal: plpgsql - Assert statement

Hi any comments to last proposal and patch? Pavel 2014-11-26 19:52 GMT+01:00 Pavel Stehule : > > Hi > > 2014-11-26 16:46 GMT+01:00 Pavel Stehule : > >> >> >> 2014-11-26 13:31 GMT+01:00 Marko Tiikkaja : >> >>> On 11/26/14 8:55 AM, Pavel Stehule wrote: >>> * should be assertions globally enab

Re: [HACKERS] proposal: plpgsql - Assert statement

Hi 2014-11-26 16:46 GMT+01:00 Pavel Stehule : > > > 2014-11-26 13:31 GMT+01:00 Marko Tiikkaja : > >> 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

Re: [HACKERS] proposal: plpgsql - Assert statement

2014-11-26 13:31 GMT+01:00 Marko Tiikkaja : > 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 loca

Re: [HACKERS] proposal: plpgsql - Assert statement

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 ad

Re: [HACKERS] proposal: plpgsql - Assert statement

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 p

Re: [HACKERS] proposal: plpgsql - Assert statement

On Mon, Nov 24, 2014 at 2:07 PM, Tom Lane 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 we do in PL/pgsq

Re: [HACKERS] proposal: plpgsql - Assert statement

Robert Haas writes: > On Sun, Nov 23, 2014 at 4:40 PM, Tom Lane 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 make it painless to invent an >> A

Re: [HACKERS] proposal: plpgsql - Assert statement

On Sun, Nov 23, 2014 at 4:40 PM, Tom Lane 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? The only re

Re: [HACKERS] proposal: plpgsql - Assert statement

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

Re: [HACKERS] proposal: plpgsql - Assert statement

On 19 November 2014 23:29, Tom Lane wrote: > Pavel Stehule writes: >> 2014-11-19 23:54 GMT+01:00 Tom Lane : >>> 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-intro

Re: [HACKERS] proposal: plpgsql - Assert statement

Pavel Stehule writes: > 2014-11-19 23:54 GMT+01:00 Tom Lane : >> 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? > Doesn't

Re: [HACKERS] proposal: plpgsql - Assert statement

2014-11-19 23:54 GMT+01:00 Tom Lane : > Marko Tiikkaja 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.c

Re: [HACKERS] proposal: plpgsql - Assert statement

2014-11-19 23:38 GMT+01:00 Marko Tiikkaja : > On 2014-11-19 23:18, Pavel Stehule wrote: > >> 2014-11-19 18:01 GMT+01:00 Tom Lane : >> >> Robert Haas writes: >>> On Wed, Nov 19, 2014 at 11:13 AM, Tom Lane wrote: > FWIW, I would vote against it also. I do not find this to be a natu

Re: [HACKERS] proposal: plpgsql - Assert statement

Marko Tiikkaja 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 that we'd hav

Re: [HACKERS] proposal: plpgsql - Assert statement

On 2014-11-19 23:18, Pavel Stehule wrote: 2014-11-19 18:01 GMT+01:00 Tom Lane : Robert Haas writes: On Wed, Nov 19, 2014 at 11:13 AM, Tom Lane 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 issues. (In parti

Re: [HACKERS] proposal: plpgsql - Assert statement

2014-11-19 18:01 GMT+01:00 Tom Lane : > Robert Haas writes: > > On Wed, Nov 19, 2014 at 11:13 AM, Tom Lane 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 issues. (In > particular, > >> what is the evalua

Re: [HACKERS] proposal: plpgsql - Assert statement

2014-11-19 17:43 GMT+01:00 Robert Haas : > On Wed, Nov 19, 2014 at 11:13 AM, Tom Lane wrote: > > Andrew Dunstan 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

Re: [HACKERS] proposal: plpgsql - Assert statement

2014-11-19 17:13 GMT+01:00 Tom Lane : > Andrew Dunstan 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 v

Re: [HACKERS] proposal: plpgsql - Assert statement

On Wed, Nov 19, 2014 at 12:01 PM, Tom Lane wrote: > Robert Haas writes: >> On Wed, Nov 19, 2014 at 11:13 AM, Tom Lane 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 issues. (In particular, >>> what is the

Re: [HACKERS] proposal: plpgsql - Assert statement

Robert Haas writes: > On Wed, Nov 19, 2014 at 11:13 AM, Tom Lane 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 issues. (In particular, >> what is the evaluation order of the WHEN versus the other subexpressi

Re: [HACKERS] proposal: plpgsql - Assert statement

On Wed, Nov 19, 2014 at 11:13 AM, Tom Lane wrote: > Andrew Dunstan 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 tha

Re: [HACKERS] proposal: plpgsql - Assert statement

Andrew Dunstan 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, plus >> 3 in

Re: [HACKERS] proposal: plpgsql - Assert statement

> > >> On 18 November 2014 21:19, Petr Jelinek 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 >>> f

Re: [HACKERS] proposal: plpgsql - Assert statement

On 11/19/2014 06:35 AM, Simon Riggs wrote: On 18 November 2014 21:19, Petr Jelinek 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 na

Re: [HACKERS] proposal: plpgsql - Assert statement

On 18 November 2014 21:19, Petr Jelinek 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 > me... That's a re

Re: [HACKERS] proposal: plpgsql - Assert statement

2014-11-18 22:28 GMT+01:00 Andrew Dunstan : > > On 11/18/2014 04:11 PM, Pavel Stehule wrote: > >> >> >> 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: >> >> >>

Re: [HACKERS] proposal: plpgsql - Assert statement

On 11/18/2014 04:11 PM, Pavel Stehule wrote: 2014-11-18 21:27 GMT+01:00 Andrew Dunstan >: 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

Re: [HACKERS] proposal: plpgsql - Assert statement

On 18/11/14 22:11, Pavel Stehule wrote: 2014-11-18 21:27 GMT+01:00 Andrew Dunstan 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 :) I understand well t

Re: [HACKERS] proposal: plpgsql - Assert statement

2014-11-18 21:27 GMT+01:00 Andrew Dunstan : > > 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 somethi

Re: [HACKERS] proposal: plpgsql - Assert statement

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 synt

Re: [HACKERS] proposal: plpgsql - Assert statement

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 doesn't

Re: [HACKERS] proposal: plpgsql - Assert statement

2014-11-18 17:08 GMT+01:00 Simon Riggs : > On 18 November 2014 12:29, Pavel Stehule 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 control > > statements in p

Re: [HACKERS] proposal: plpgsql - Assert statement

On 18 November 2014 12:29, Pavel Stehule 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 control > statements in plpgsql is consistent. I don't want to break it (more, > pro

Re: [HACKERS] proposal: plpgsql - Assert statement

On 11/18/2014 04:23 AM, Simon Riggs wrote: On 18 November 2014 01:00, Jim Nasby 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

Re: [HACKERS] proposal: plpgsql - Assert statement

2014-11-18 10:23 GMT+01:00 Simon Riggs : > On 18 November 2014 01:00, Jim Nasby 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 pr

Re: [HACKERS] proposal: plpgsql - Assert statement

On 18 November 2014 01:00, Jim Nasby 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 to

Re: [HACKERS] proposal: plpgsql - Assert statement

2014-11-17 23:58 GMT+01:00 Simon Riggs : > >> 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 every parameter, whe

Re: [HACKERS] proposal: plpgsql - Assert statement

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 fo

Re: [HACKERS] proposal: plpgsql - Assert statement

>> 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 chan

Re: [HACKERS] proposal: plpgsql - Assert statement

2014-10-17 9:14 GMT+02:00 Petr Jelinek : > On 16/10/14 13:29, Pavel Stehule wrote: > >> Hi >> >> 2014-10-14 22:57 GMT+02:00 Petr Jelinek > >> 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

Re: [HACKERS] proposal: plpgsql - Assert statement

On 16/10/14 13:29, Pavel Stehule wrote: Hi 2014-10-14 22:57 GMT+02:00 Petr Jelinek Great, looks good to me, marking as ready for committer. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mail

Re: [HACKERS] proposal: plpgsql - Assert statement

Hi 2014-10-14 22:57 GMT+02:00 Petr Jelinek : > 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 P

Re: [HACKERS] proposal: plpgsql - Assert statement

2014-10-15 11:57 GMT+02:00 Ali Akbar : > 2014-09-30 10:04 GMT+07:00 Jim Nasby : > >> 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, arbitra

Re: [HACKERS] proposal: plpgsql - Assert statement

2014-09-30 10:04 GMT+07:00 Jim Nasby : > 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 >> wel

Re: [HACKERS] proposal: plpgsql - Assert statement

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 * allow

Re: [HACKERS] proposal: plpgsql - Assert statement

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 in a development environment too. And I am very sure that

Re: [HACKERS] proposal: plpgsql - Assert statement

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. I

Re: [HACKERS] proposal: plpgsql - Assert statement

2014-09-17 21:36 GMT+02:00 Peter Eisentraut : > 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 han

Re: [HACKERS] proposal: plpgsql - Assert statement

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 expres

Re: [HACKERS] proposal: plpgsql - Assert statement

2014-09-17 21:00 GMT+02:00 Peter Eisentraut : > 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

Re: [HACKERS] proposal: plpgsql - Assert statement

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,

Re: [HACKERS] proposal: plpgsql - Assert statement

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 ne

Re: [HACKERS] proposal: plpgsql - Assert statement

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 v

Re: [HACKERS] proposal: plpgsql - Assert statement

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 querie

Re: [HACKERS] proposal: plpgsql - Assert statement

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 iss

Re: [HACKERS] proposal: plpgsql - Assert statement

2014-09-09 7:54 GMT+02:00 Craig Ringer : > 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

Re: [HACKERS] proposal: plpgsql - Assert statement

2014-09-09 7:55 GMT+02:00 Craig Ringer : > 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

Re: [HACKERS] proposal: plpgsql - Assert statement

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 tri

Re: [HACKERS] proposal: plpgsql - Assert statement

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 P

Re: [HACKERS] proposal: plpgsql - Assert statement

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/PgSQ

Re: [HACKERS] proposal: plpgsql - Assert statement

On Fri, Sep 5, 2014 at 2:16 AM, 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

Re: [HACKERS] proposal: plpgsql - Assert statement

2014-09-06 19:59 GMT+02:00 Marko Tiikkaja : > 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

Re: [HACKERS] proposal: plpgsql - Assert statement

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 su

Re: [HACKERS] proposal: plpgsql - Assert statement

2014-09-06 19:26 GMT+02:00 Marko Tiikkaja : > On 2014-09-06 7:27 AM, Pavel Stehule wrote: > >> 2014-09-05 14:35 GMT+02:00 Jan Wieck : >> >>> 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

Re: [HACKERS] proposal: plpgsql - Assert statement

On 2014-09-06 7:27 AM, Pavel Stehule wrote: 2014-09-05 14:35 GMT+02:00 Jan Wieck : 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 a agreement th

Re: [HACKERS] proposal: plpgsql - Assert statement

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 http://www.2ndQuadran

Re: [HACKERS] proposal: plpgsql - Assert statement

2014-09-05 14:35 GMT+02:00 Jan Wieck : > On 09/05/2014 04:40 AM, Pavel Stehule wrote: > >> >> >> >> 2014-09-05 10:33 GMT+02:00 Marko Tiikkaja > >: >> >> On 9/5/14 10:09 AM, Pavel Stehule wrote: >> >> I think this could still be parsed correctly, though I'm not

Re: [HACKERS] proposal: plpgsql - Assert statement

On 09/05/2014 04:40 AM, Pavel Stehule wrote: 2014-09-05 10:33 GMT+02:00 Marko Tiikkaja 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: ASSERT W

Re: [HACKERS] proposal: plpgsql - Assert statement

2014-09-05 11:17 GMT+02:00 Marko Tiikkaja : > On 9/5/14 11:08 AM, Pavel Stehule wrote: > >> 2014-09-05 10:57 GMT+02:00 Marko Tiikkaja : >> >>> 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 unders

Re: [HACKERS] proposal: plpgsql - Assert statement

On 9/5/14 11:08 AM, Pavel Stehule wrote: 2014-09-05 10:57 GMT+02:00 Marko Tiikkaja : 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 conformity of prop

Re: [HACKERS] proposal: plpgsql - Assert statement

2014-09-05 10:57 GMT+02:00 Marko Tiikkaja : > On 9/5/14 10:40 AM, Pavel Stehule wrote: > >> 2014-09-05 10:33 GMT+02:00 Marko Tiikkaja : >> >>> 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

Re: [HACKERS] proposal: plpgsql - Assert statement

On 9/5/14 10:40 AM, Pavel Stehule wrote: 2014-09-05 10:33 GMT+02:00 Marko Tiikkaja : 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 parsing until th

Re: [HACKERS] proposal: plpgsql - Assert statement

2014-09-05 10:33 GMT+02:00 Marko Tiikkaja : > 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

Re: [HACKERS] proposal: plpgsql - Assert statement

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 c

Re: [HACKERS] proposal: plpgsql - Assert statement

2014-09-05 9:52 GMT+02:00 Marko Tiikkaja : > 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 intern

Re: [HACKERS] proposal: plpgsql - Assert statement

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 intern

[HACKERS] proposal: plpgsql - Assert statement

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.