Change CLIENT_ENCODING to client_encoding plus a question on "SET NAMES"
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/13/multibyte.html Description: Here is a tiny modification at [1] (change CLIENT_ENCODING to lowercase): -SET CLIENT_ENCODING TO 'value'; +SET client_encoding TO 'value'; Besides that, please allow me ask a question. The PG doc at[1] said "you can use the standard SQL syntax SET NAMES for this purpose", and it works. But no PG help-doc describes this SQL syntax of "SET NAMES". Is it on purpose or missed? I'd be grateful if anyone can share me the rule on whether or not to add a SQL syntax in PG help-doc. [1]https://www.postgresql.org/docs/13/multibyte.html
Incorrect Syntax in Function Syntax diagram
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/13/sql-createfunction.html Description: | IMMUTABLE | STABLE | VOLATILE | [ NOT ] LEAKPROOF [ NOT ] LEAKPROOF is accepting separately , So why you written [ NOT ] LEAKPROOF with | IMMUTABLE | STABLE | VOLATILE | Please separate the [ NOT ] LEAKPROOF from the OR list Note: Your documentation must be correct
Re: Incorrect Syntax in Function Syntax diagram
On Wed, Jun 23, 2021 at 6:31 AM PG Doc comments form
wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/13/sql-createfunction.html
> Description:
>
> | IMMUTABLE | STABLE | VOLATILE | [ NOT ] LEAKPROOF
>
> [ NOT ] LEAKPROOF is accepting separately ,
> So why you written [ NOT ] LEAKPROOF with | IMMUTABLE | STABLE | VOLATILE
> |
>
>
The commit message doesn't say - but I can see how from a technical
perspective that the claim that something is immutable is considered
similar to a claim that something has no side effects, thus there is a
connection. As noted below, the fact that the first three are mutually
exclusive while leakproof is not is convincing enough a reason to list
leakproof separately.
Please separate the [ NOT ] LEAKPROOF from the OR list
>
I would agree, and would add that I wonder whether the syntax for the three
mutually exclusive options should be shown as such instead of having to
read that in the description notes. Does writing < | { IMMUTABLE | STABLE
| VOLATILE } > work?
Note: Your documentation must be correct
>
Is that so? It is a good thing then that it is presently correct and that
this is just a readability suggestion. The presence of them all on the
same line does not by itself imply any kind of relationship in the actual
grammar.
David J.
Re: Incorrect Syntax in Function Syntax diagram
"David G. Johnston" writes:
> On Wed, Jun 23, 2021 at 6:31 AM PG Doc comments form
> wrote:
> Please separate the [ NOT ] LEAKPROOF from the OR list
> I would agree, and would add that I wonder whether the syntax for the three
> mutually exclusive options should be shown as such instead of having to
> read that in the description notes. Does writing < | { IMMUTABLE | STABLE
> | VOLATILE } > work?
Yeah. The way it's written fails to show, except via formatting,
that IMMUTABLE/STABLE/VOLATILE are mutually exclusive; and then
somebody came along and destroyed the formatting. I agree both
with adding braces and with putting LEAKPROOF on its own line.
The latter is/should be only cosmetic; but the rest of the list
has one line per independent option, and LEAKPROOF is surely
independent of the volatility options.
regards, tom lane
Re: Incorrect Syntax in Function Syntax diagram
On Wed, Jun 23, 2021 at 8:29 AM Tom Lane wrote: > Yeah. The way it's written fails to show, except via formatting, > that IMMUTABLE/STABLE/VOLATILE are mutually exclusive; > It seems the STRICT -ness line needs brackets too then. Also, back to volatility, volatile is the default option though due to alphabetical order it is shown last with no indication it is the default. Do we have an existing convention in the syntax section to indicate defaults, either with emphasis, placement, or even an annotation like "*"? David J.
Re: Incorrect Syntax in Function Syntax diagram
"David G. Johnston" writes: > Do we have an existing convention in the syntax section to indicate > defaults, either with emphasis, placement, or even an annotation like "*"? No. The syntax diagrams verge on unreadability already, so I'm unconvinced that trying to overload them with this issue would be wise. regards, tom lane
Re: Reverse btree indexes
On 2021-Jun-22, David G. Johnston wrote:
> On Tue, Jun 22, 2021 at 2:28 PM Zach Aysan wrote:
> >> for example, col LIKE 'foo%' or col ~ '^foo', but not col LIKE '%bar',
> >> which would require a reversed index on the field. To use the reversed
> >> index, query with reverse(col) like reverse('%bar').
> >
> This type of commentary isn't usually something we include in the
> documentation...and I'm not too keen on "reversed index" as a phrase
> regardless.
Maybe we can add it as a parenthical comment. Something like
: The optimizer can also use a B-tree index for queries involving the
: pattern matching operators LIKE and ~ if the pattern is a constant and
: is anchored to the beginning of the string — for example, col LIKE
: 'foo%' or col ~ '^foo', but not col LIKE '%bar' (it is possible to
: use an expressional index to support queries such as the latter; see
: Section 11.7). However, [...]
Then add an example in 11.7 Indexes on Expressions below the two
existing examples. I think this is a noteworthy use of expressional
indexes; I've had to explain the reverse() idea a couple of times.
--
Álvaro Herrera39°49'30"S 73°17'W
"The eagle never lost so much time, as
when he submitted to learn of the crow." (William Blake)
