Re: Improving PL/PgSQL (was: Re: plpgsql defensive mode)

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: Improving PL/PgSQL (was: Re: plpgsql defensive mode)
Дата
Msg-id CAFj8pRBigW7rPariaT+nBv6S5=KUBwL3Qye2QaDhv-5z0PoLJA@mail.gmail.com
обсуждение исходный текст
Ответ на Improving PL/PgSQL (was: Re: plpgsql defensive mode)  (Marko Tiikkaja <marko@joh.to>)
Ответы Re: Improving PL/PgSQL (was: Re: plpgsql defensive mode)  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: Improving PL/PgSQL  (Marko Tiikkaja <marko@joh.to>)
Список pgsql-hackers



2014-09-06 20:08 GMT+02:00 Marko Tiikkaja <marko@joh.to>:
On 2014-09-06 7:56 PM, Pavel Stehule wrote:
2014-09-06 19:54 GMT+02:00 Marko Tiikkaja <marko@joh.to>:
Then that doesn't really solve our problem.  Switching between two
languages on a per-function basis, when both look exactly the same but have
very different semantics would be a nightmare.


It is maximum what is possible

use a different language instead

Sigh.

OK, let's try and forget the cardinality assertions we've been talking about in the other thread(s).  I seem to recall there being a generally welcoming atmosphere in the discussion about adding a set of pragmas (or options/whatever) to make some of PL/PgSQL's flaws go away, in a non-backwards compatible way.  From the list here: https://wiki.postgresql.org/wiki/Improving_PL/PgSQL_(September_2014) do you think at least some of those would be reasonable candidates for these pragmas?  Do you see others ones that are missing from this list?

Please also keep discussion about ASSERT in the thread for that, and the suggestion under "Single-row operations" out of this.

SELECT .. INTO vs. TOO_MANY_ROWS

+1 .. possible every where

Variable assignments

+1 .. only in "defensive mode"

Single-row operations

+1 .. only in "defensive mode" without special syntax

EXECUTE and FOUND

-1 .. it is emulation of PL/SQL behave.. so introduction can do too high unhappy surprise if somebody will migrate to Oracle -- the syntax is too similar 

OUT parameters

-1 .. to proposal .. It is in contradiction with current feature. Next it is nonsense. INTO clause should to contains only plpgsql variables - in 9.x Postgres there is not possible issue.
postgres=# create table x(a int, b int);
CREATE TABLE
postgres=# insert into x values(10,20);
INSERT 0 1
postgres=# create or replace function foo(out a int, out b int)
postgres-# returns record as $$
postgres$# begin
postgres$#   select x.a, x.b from x into a, b;
postgres$#   return;
postgres$# end;
postgres$# $$ language plpgsql;
CREATE FUNCTION
postgres=# select * from foo();
 a  | b 
----+----
 10 | 20
(1 row)


you can see, there is not any collision

Assertions

-1 to proposed syntax - I wrote about my reasons in other thread.

Regards

Pavel




.marko

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

Предыдущее
От: Jan Wieck
Дата:
Сообщение: Re: Improving PL/PgSQL
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: Final Patch for GROUPING SETS - unrecognized node type: 347