Re: PL/pgSQL 1.2

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: PL/pgSQL 1.2
Дата
Msg-id CAFj8pRDxHkWsd82gDmx-NRJuofmJ8JS=m8iPTcFLvWzBh8St8g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: PL/pgSQL 1.2  (Joel Jacobson <joel@trustly.com>)
Ответы Re: PL/pgSQL 1.2  (Marko Tiikkaja <marko@joh.to>)
Re: PL/pgSQL 1.2  (Joel Jacobson <joel@trustly.com>)
Список pgsql-hackers



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.


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Marko Tiikkaja
Дата:
Сообщение: Re: PL/pgSQL 1.2
Следующее
От: Marko Tiikkaja
Дата:
Сообщение: Re: PL/pgSQL 1.2