2014-09-04 10:06 GMT+02:00 Joel Jacobson <j...@trustly.com>: > On Thu, Sep 4, 2014 at 9:39 AM, Pavel Stehule <pavel.steh...@gmail.com> > wrote: > > we have totally different opinion what is good > > Can you elaborate on that? >
I would to elaborate on enhancing plpgsql - but my primary target is readability without necessity of special special statements, types. I am strong against to create some shortcuts for relative too special use case. > > Your "ASSERT CHECK ROWCOUNT = 1;" is lengthly, which is why I don't like > it. > Imagine if having to type > my $var =========================== 'foo'; > instead of > my $var = 'foo'; > on every single line of could where you want to assign a variable, > that would just be ridiculous. > > If you have a typical CRUD application and decide to do *all* data > operations via PL functions, > which is a design pattern advocated by many*, then you will end up > with a lot of very simple > short PL functions, to do things like update_worker_status(), > set_notification_response(), etc, > in which you always pass something which is a primary key in some > table, and want to update > exactly one row. Having to type 27 extra characters for every single > line of code, instead of the > suggested 3 extra characters, is a big difference, for anyone who > designs a CRUD application > which relies on the usage of PL functions. > Is not better to design special PL for this usage? I understand to your motivation, but it is not acceptable for me in plpgsql. Ten years ago, we had to solve similar problem - and we designed metalanguage that was translated to plpgsql. > > For me, it would be useful to understand if you are developing CRUD > applications, > or if your main usage for PL/pgSQL functions are other things? > I am strong in opinion so PLpgSQL is targeted primary for implementation business logic in server side. CRUD is only one from possible use cases - and without any special importance to others. > > If the latter, then maybe that could explain why you don't feel strongly > about > simplifying and condensing the syntax for the most common use-case of them > all. > I don't agree so what you propose, it is common use case. And I don't think so it can be used in synergy with current design > > *) but there are probably equally who prefer to handle business logics > outside the database > It is maybe main difference between me and you. Usually I don't write CRUD applications, and I am not sure if plpgsql is good for CRUD. Mainly I would not to optimize plpgsql primary for CRUD.
