Re: PL/pgSQL 1.2 - Mailing list pgsql-hackers

On Thu, Sep 4, 2014 at 10:42 AM, Pavel Stehule <pavel.stehule@gmail.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

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.stehule@gmail.com> wrote:
>
>
>
> 2014-09-04 10:06 GMT+02:00 Joel Jacobson <joel@trustly.com>:
>
>> On Thu, Sep 4, 2014 at 9:39 AM, Pavel Stehule <pavel.stehule@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.
>
>