Re: proposal: schema variables - doc

Pavel Stehule <pavel.stehule@gmail.com>

From: Pavel Stehule <pavel.stehule@gmail.com>
To: Erik Rijkers <er@xs4all.nl>
Cc: Michael Paquier <michael@paquier.xyz>, Zhihong Yu <zyu@yugabyte.com>, Amit Kapila <amit.kapila16@gmail.com>, DUVAL REMI <REMI.DUVAL@cheops.fr>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-03-22T09:47:07Z
Lists: pgsql-hackers, pgsql-performance

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Move WAL sequence code into its own file

  2. Add ExplainState argument to pg_plan_query() and planner().

  3. Don't include access/htup_details.h in executor/tuptable.h

  4. Refactor to avoid code duplication in transformPLAssignStmt.

  5. Avoid including commands/dbcommands.h in so many places

  6. Restrict psql meta-commands in plain-text dumps.

  7. Split func.sgml into more manageable pieces

  8. Fix squashing algorithm for query texts

  9. EXPLAIN: Always use two fractional digits for row counts.

  10. Preliminary refactoring of plpgsql expression construction.

  11. plpgsql: pure parser and reentrant scanner

  12. Add some sanity checks in executor for query ID reporting

  13. Fix misleading error message context

  14. Add macros for looping through a List without a ListCell.

Attachments

Hi

st 17. 3. 2021 v 13:05 odesílatel Erik Rijkers <er@xs4all.nl> napsal:

>
> > On 2021.03.13. 07:01 Pavel Stehule <pavel.stehule@gmail.com> wrote:
> > Hi
> > fresh rebase
> > [schema-variables-20210313.patch.gz]
>
>
> Hi Pavel,
>
> I notice that the phrase 'schema variable' is not in the index at the end
> ('bookindex.html').  Not good.
>
> It is also not in the index at the front of the manual - also not good.
>
> Maybe these two (front and back index) can be added?
>

I inserted new indexterm "schema variable", and now this part of
bookindex.html looks like:

schema variablealtering, ALTER VARIABLEchanging, LETdefining, CREATE
VARIABLEdescription, Descriptionremoving, DROP VARIABLE



>
> If a user searches the pdf, the first occurrence he finds is at:
>
>   43.13.2.4. Global variables and constants
>   (in itself that occurrence/mention is all right, but is should not be
> the first find, I think)
>
> (I think there was in earlier versions of the patch an entry in the
> 'contents', i.e., at the front of the manual).  I think it would be good to
> have it in the front-index, pointing to either LET or CREATE VARIABLE, or
> maybe even to a small introductory paragraph somewhere else (again, I seem
> to remember that there was one in an earlier patch version).
>


I wrote new section to "advanced features" about schema variables


>
>
> Of the new commands that this patch brings, 'LET' is the most immediately
> illuminating for a user (even when a CREATE VARIABLE has to be done first.
> There is an entry 'LET' in the index (good), but it would be better if that
> with LET-entry too the phrase 'schema variable' occurred.  (I don't know if
> that's possible)
>
>
> Then, in the CREATE VARIABLE paragraphs it says
>    'Changing a schema variable is non-transactional by default.'
>
> I think that, unless there exists a mode where schema vars can be made
> transactional, 'by default' should be deleted (and there is no such
> 'transactional mode' for schema variables, is there?).  The 'Description'
> also has such a 'By default' which is better removed for the same reason.
>

fixed


>
> In the CREATE VARIABLE page the example is:
>
> CREATE VARIABLE var1 AS integer;
> SELECT var1;
>
> I suggest to make that
>
> CREATE VARIABLE var1 AS date;
> LET var1 = (select current_date);
> SELECT var1;
>
> So that the example immediately shows an application of functionality.
>

done

Thank you for the documentation review.

Updated patch attached

Regards

Pavel



>
> Thanks,
>
> Erik Rijkers
>
>
>
>
>
>
>
>
>
>
>
>
>
> >
> > Pavel
>