2014-09-04 10:57 GMT+02:00 Joel Jacobson <j...@trustly.com>: > On Thu, Sep 4, 2014 at 10:42 AM, Pavel Stehule <pavel.steh...@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 > > 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.steh...@gmail.com> > wrote: > > > > > > > > 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. > > > > >