Re: PL/pgSQL 1.2

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



2014-09-04 13:54 GMT+02:00 Marko Tiikkaja <marko@joh.to>:
On 9/4/14 1:47 PM, Pavel Stehule wrote:
2014-09-04 13:37 GMT+02:00 Marko Tiikkaja <marko@joh.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

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

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Scaling shared buffer eviction
Следующее
От: Robert Haas
Дата:
Сообщение: Re: PL/pgSQL 1.2