Thanks for the updated patch set.
I found a problem in 0019-transactional-variables.patch:
--- a/doc/src/sgml/catalogs.sgml
+++ b/doc/src/sgml/catalogs.sgml
@@ -9851,6 +9851,17 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l
</para></entry>
</row>
+ <row>
+ <entry><structfield>varistransact</structfield></entry>
+ <entry><type>boolean</type></entry>
+ <entry></entry>
+ <entry>
+ True, when the variable is "transactional". In case of transaction
+ rollback, transactional variables are reset to their content at the
+ transaction start. The default value is false.
+ </entry>
+ </row>
That's messed up; it should be
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>varistransact</structfield> <type>boolean</type>
</para>
<para>
True, when the variable is <quote>transactional</quote>. In the case
of a transaction rollback, transactional variables are reset to the
value they had when the transaction started. The default value is
<literal>false</literal>.
</para></entry>
</row>
changed
I have started reading through the first patch, and so far I have only found
language problems.
I wonder how I should go about this. At first, I intended to send an edited
version of the first patch, but as later patches depend on earlier patches,
that would mess up the patch set.
I can send my suggested modifications in text, but then you have to copy and
paste them all, which is cumbersome.
What would be best for you?
send me it in any form - probably the diff of patches are best. I'll do necessary fixes.
There are not good tool for maintaining chronologically incremental patchset
Thinking further, I wondered about the order of patches.
If some committer eventually takes mercy on this patch set, I expect that
only a part of the functionality will go in as a first step.
Does the order of the patches in the patch set match such a process?
yes
we talk so first seven patches are mandatory - others are optional and introduce new functionality or increase performance
I'd guess that temporary session variables or ON TRANSACTION END RESET
would be things that can be committed later on, but PL/pgSQL support
should be in the first commit.
The plpgsql is supported by a second patch, because variables are accessible by queries. But patch 16 introduces the
PLpgSQL LET command, and then allows us to evaluate an expression as a simple expression, which is significantly faster.
What is your approach to that?
The first six, seven patches are fundamental. For others we can talk about priorities. I see performance related patches to be more important, but they are a little bit more technically difficult or maybe related to a not too cool area now (like PL/pgSQL - I like it, but almost all people's stored procedures aren't used). Implementation of new features is almost done by simple patches. And again for somebody temp variables are not important (usage temp variables in PLpgSQL is +/- zero), but for others can be very important (it can be very interesting for writing psql scripts, because it allows parametrization of DO commands, and it is cheaper than temp tables for passing result).
So others patches have some order, because there has to be some order, but it is not final or immutable. I can imagine throwing these patches to different patchset. On the second hand, the size of these patches is less than the first two, and I think it is interesting, because from my perspective, these patches cover this area completely. But again, the order of these patches is important for some dependencies in files (regress tests), but it doesn't draw the priority of implemented features. Current state is the result of my work or work of other peoples that did review of these patches. I am open to changing this order, if somebody would do it.
Regards
Pavel
Yours,
Laurenz Albe