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.
