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 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? > > There is one stronger difference - there is clean, what is targer of assertation, because there is defined semantic.
When all is just any expression, there is nothing specified semantic > ( 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. > bit harder, with possibility to false identification > > > .marko >
