Hello Pavel,
>> Here is a v13, which is just a rebase after the documentation xml-ization.
Here is a v14, after yet another rebase, and some comments added to answer
your new comments.
> I am looking to this patch.
>
> Not sure if "cset" is best name - maybe "eset" .. like embeded set?
I used c for "compound", because they compound SQL commands.
Now I do not have a very strong opinion, only that it should be some
letter which some logic followed by "set".
The variables and fields in the source currently use "compound"
everywhere, if this is changed they should be updated accordingly.
ISTM that the ";" is embedded, but the commands are compound, so
"compound" seems better word to me. However it is debatable.
If there some standard naming for the concept, it should be used.
> The code of append_sql_command is not too readable and is not enough
> commented.
Ok. I have added comments in the code.
> I don't understand why you pass a param compounds to append_sql_command,
> when this value is stored in my_command->compound from create_sql_command?
This is the number of compound commands in the "more" string. It must be
updated as well as the command text, so that the my_command text and
number of compounds is consistant.
Think of one initialization followed by two appends:
SELECT 1 AS x \cset
SELECT 2 \; SELECT 3 AS y \cset
SELECT 4 \; SELECT 5 \; SELECT 6 AS z \gset
In the end, we must have the full 6 queries
"SELECT 1 AS x \; SELECT 2 \; SELECT 3 AS y \; SELECT 4 \; SELECT 5 \; SELECT 6 AS z"
and know that we want to set variables from queries 1, 3 and 6 and ignore
the 3 others.
> Or maybe some unhappy field or variable names was chosen.
It seems ok to me. What would your suggest?
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers