Re: PL/pgSQL 1.2

2014-09-04 10:06 GMT+02:00 Joel Jacobson <joel(at)trustly(dot)com>:

> On Thu, Sep 4, 2014 at 9:39 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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.