Re: PL/pgSQL 1.2

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Marko Tiikkaja <marko(at)joh(dot)to>
Cc: Hannu Krosing <hannu(at)2ndquadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Joel Jacobson <joel(at)trustly(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PL/pgSQL 1.2
Date: 2014-09-04 12:04:38
Message-ID: CAFj8pRDMhSwfjdSjNiFcvc6T-j-vZ7t16bKhB8U1sihXxhVMTw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2014-09-04 13:54 GMT+02:00 Marko Tiikkaja <marko(at)joh(dot)to>:

> On 9/4/14 1:47 PM, Pavel Stehule wrote:
>
>> 2014-09-04 13:37 GMT+02:00 Marko Tiikkaja <marko(at)joh(dot)to>:
>>
>>> I've started a wiki page with the list of the things I could think of at
>>>
>>> this very moment. I probably got the most annoying ones in there, but I
>>> also might have forgotten about some things. I invite discussion of
>>> every
>>> suggestion on -HACKERS.
>>>
>>
>> where I can wrote comments?
>>
>
> I guess comments could be added as a subsection if you feel -HACKERS
> doesn't work.

ok

>
>
> I am sorry, It is difficult - your usage of plpgsql is sometimes less,
>> some
>> times more against best practices :(
>>
>
> Best practices according to whom? And which parts, exactly? There's
> quite a lot of stuff in there, both explicitly stated and implicitly
> assumed.
>
>
> PL functions should not be only envelope to SQL statement
>>
>
> I disagree, to some extent. Our "external" applications interface with
> the database only by calling functions (which are often written in
> PL/PgSQL). If that function has no more work to do than to run a single
> query, then yes, the function will just serve as an envelope to a single
> query. But that also allows the function to be changed in the future
> without having to change the application. Similarly to how you would
> expose an API when communicating with others instead of giving them a
> postgres user account and saying "update these tables" and after a month
> saying "oh, you need to remember to INSERT into this table as well or we
> won't have logs of what you did".
>

for example best practices for PL/SQL by Steven Feuerstein

We can talk about it - it subjective and I know so there are not only one
style.

For example, you can use a ALIAS to parameters if you have a problem with
parameter variables

postgres=# create or replace function foo(out a int) as $$ declare _x alias
for a; begin _x := 10; end $$ language plpgsql;
CREATE FUNCTION
postgres=# select foo();
foo
-----
10
(1 row)

or if you can be more secure use a block label

postgres=# create or replace function foo(out a int) as $$ <<main>> declare
_x alias for a; begin main._x := 10; end $$ language plpgsql;
CREATE FUNCTION
postgres=# select foo();
foo
-----
10
(1 row)

The language has these possibilities. Why to add new redundant?

Pavel

>
>
> .marko
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-09-04 12:09:49 Re: PL/pgSQL 1.2
Previous Message Amit Kapila 2014-09-04 12:02:03 Re: Scaling shared buffer eviction