Re: PL/pgSQL 1.2

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

> On Thu, Sep 4, 2014 at 10:42 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
> > 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.
>
> Just curious, what kind of business logic do you write, where "one row"
> is not more special to you than "two rows" or "five rows"?
>
> Think about for a second what PL functions are able to return.
>
> Compare,
> RETURNS RECORD
> vs
> RETURNS SETOF RECORD
>
>
it is different semantic - returns composite or set of composites --- it
is not row or rows

Actually BL is usually processed oriented, so PL functions coverages
changes in data, and for queries you use SELECT

Returning SET from function is less often - and usually it is not in
preferred patterns because you can very simple block a optimizer.

> When you return from a function, you get exactly 1 row, unless
> you explicitly use the SETOF RECORD syntax, where 0...n rows are possible.
>
> To add to that, we have the STRICT keyword, which also recognize the
> fact 1 row is special.
>
> So, we already *have* special handling for the 1 row case in many areas.
>
> I cannot see how you can fail to agree it would be a good thing to
> make it simple also for UPDATE/DELETE/INSERT.
>
>
>
> On Thu, Sep 4, 2014 at 10:42 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
> >
> >
> >
> > 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.
> >
> >
>