Re: proposal: plpgsql - Assert statement - Mailing list pgsql-hackers

On 9/5/14 11:08 AM, Pavel Stehule wrote:

2014-09-05 10:57 GMT+02:00 Marko Tiikkaja <marko@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 conformity of proposed tools. Sure,  all can
reduced to ASSERT(expr) .. but where is some benefit against function call

I see several benefits:

   1) Standard syntax, available anywhere
   2) Since the RAISE EXCEPTION happens at the caller's site, we can
provide information not available to an ordinary function, such as the
values of the parameters passed to it
   3) We can make the exception uncatchable
   4) ASSERTs can be easily disabled (if we choose to allow that), even
per-function

All points can be solved  by extension on PGXN ..

#3 probably.  Being able to satisfy #1 through PGXN is ridiculous.  #2 and #4 would require at least hooking into PL/PgSQL, which might be possible, but it's intrusive and honestly feels fragile.

But perhaps more to the point, why would that criticism apply to my suggestion, but not yours?  Why don't we just reject any ASSERT syntax?

and your proposed syntax
can be better processed on Postgres level than PLpgSQL level.

*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 am able to do without any change of language as plpgsql extension -

there
is no necessary to do any change for too thin proposal

What *exactly* about my proposal is "too thin"?  What does your thing do
that mine doesn't?  If you're saying your suggestion allows us to give a
better error message, I disagree:

"Too thin" it means so there is not possibility to extensibility,
possibility to define dafaults, possibility to use it for static analyse.

Again, why does this criticism only apply to my suggestion and not yours?

   ( ROW_COUNT ( = | <> ) ( 1 | 0 ) |

I've already addressed this: we can print the parameters and their values
automatically, so printing the row count here doesn't give any additional
value.

In this case, I can use a plpgsql parser for static analyse - I can do
warning, if related query has not filter PK and similar.

You can do that anyway, you just need to work a bit harder.  I don't see the problem, really.

.marko