> SELECT 1 AS one \;
> SELECT 2 AS two UNION SELECT 2 \;
> SELECT 3 AS three \aset
>
> will set both "one" and "three", while "two" is not set because there were
> two rows. It is a kind of more permissive \gset.
Are you sure two is not set :)?
SELECT 2 AS two UNION SELECT 2; -- only returns one row.
but
SELECT 2 AS two UNION SELECT 10; -- returns the two rows.
Is this the expected behavior with \aset? In my opinion throwing a valid error
like "client 0 script 0 command 0 query 0: expected one row, got 2" make more
sense.
- With \gset
SELECT 2 AS two UNION SELECT 10 \gset
INSERT INTO test VALUES(:two,0,0);
$ pgbench postgres -f pgbench_aset.sql -T 1 -j 1 -c 1 -s 10
starting vacuum...end.
client 0 script 0 command 0 query 0: expected one row, got 2
transaction type: pgbench_aset.sql
scaling factor: 10
query mode: simple
number of clients: 1
number of threads: 1
duration: 1 s
number of transactions actually processed: 0
Run was aborted; the above results are incomplete.
- With \aset
SELECT 2 AS two UNION SELECT 10 \aset
INSERT INTO test VALUES(:two,0,0);
vagrant@vagrant:~/percona/postgresql$ pgbench postgres -f pgbench_aset.sql -T 1
-j 1 -c 1 -s 10
starting vacuum...end.
client 0 script 0 aborted in command 1 query 0: ERROR: syntax error at or near
":"
LINE 1: INSERT INTO test VALUES(:two,0,0);
^
transaction type: pgbench_aset.sql
scaling factor: 10
query mode: simple
number of clients: 1
number of threads: 1
duration: 1 s
number of transactions actually processed: 0
Run was aborted; the above results are incomplete.
The new status of this patch is: Waiting on Author
