Re: proposal - assign result of query to psql variable

Hi Pavel,

On Tue, Oct 16, 2012 at 6:59 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
wrote:
> here is updated patch, I moved lot of code from lexer to command.com,
> and now more \gset doesn't disable other backslash commands on same
> line.

* lexer changes
IIUC, new function psql_scan_varlist_varname scans input and returns a
variable name or a comma at each call, and command.c handles the error
such as invalid # of variables. This new design seems better than old one.

However, IMHO the name psql_scan_varlist_varname sounds redundant and
unintuitive. I'd prefer psql_scan_slash_varlist, because it indicates
that that function is expected to be used for arguments of backslash
commands, like psql_scan_slash_command and psql_scan_slash_option.
Thoughts?

* multiple meta command
Now both of the command sequences

$ SELECT 1, 2 \gset var1, var2 \g foo.txt
$ SELECT 1, 2 \g foo.txt \gset var1, var2

set var1 and v2 to "1" and "2" respectively, and also write the result
into foo.txt. This would be what users expected.

* Duplication of variables
I found an issue we have not discussed. Currently \gset accepts same
variable names in the list, and stores last SELECT item in duplicated
variables. For instance,

$ SELECT 1, 2 \gset var, var

stores "2" into var. I think this behavior is acceptable, but it might
be worth mentioning in document.

* extra fixes
I fixed some minor issues below. Please see attached v10 patch for details.

* remove unused macro OT_VARLIST
* remove unnecessary #include directive for common.h
* fill comment within 80 columns
* indent short variable name with tab
* add regression test case for combination of \g and \gset

* bug on FETCH_COUNT = 1
When FETCH_COUNT is set to 1, and the number of rows returned is 1 too,
\gset shows extra "(1 row)". This would be a bug in
ExecQueryUsingCursor. Please see the last test case in regression test
psql_cmd.

I'll mark this patch as "waiting author".

Regards,
--
Shigeru HANADA