Re: dot dot dot dot
Hi Jürgen, ok if you say so. But as "" may be understood as "../.." with a forgotten slash, I would suggest to choose for instance "<...>" which is best known and understood to be replaced by whatever. And another thing more general, the tutorial suggest to compile something with "*make*" the tutorial. I think for people on Windows (they are a lot) who has not the "make" command, this is blocking. And more than that : they just have installed the binary install, and inside it, there is no "tutorial". So they have to git clone the source... which require more dev skill that normally required for a postgresql tuto. And after that they get a lesser good opinion about what is postgresql (because of poor User experience when learning basic). I would suggest to deliver directly some sql scripts that don't need compilation. Kind regards, Jean-Louis On Wed, May 13, 2020 at 9:19 PM Jürgen Purtz wrote: > > > The following documentation comment has been logged on the website: > > > > Page: https://www.postgresql.org/docs/12/tutorial-sql-intro.html > > Description: > > > > is wrong. > > The four dots are not really a part of the path. Don't use them > literally. They indicate that you should use your local path instead. > This may differ from installation to installation. > > Kind regards, Jürgen > > > -- Jean-Louis GUENEGO Tel : +33 6 12 19 81 48 mail: jlguen...@gmail.com
Re: TLS docs fixes for
> On 14 May 2020, at 04:17, Michael Paquier wrote: > > On Wed, May 13, 2020 at 11:07:44PM +0200, Daniel Gustafsson wrote: >> While working with TLS I noticed that the password callback definition had an >> extra newline in the programlisting in the docs. Since the >> has been indented with the textblock, the newline comes from whitespace being >> significant. The attached 0001 fixes by instead anchoring >> on >> column zero like how most of the docs do it. Grepping around I found one >> more >> instance of the same pattern which is also included. > > Indeed, I can see the difference. In what I spotted after applying > 0001, you are patching the one in libpq.sgml as of 0002 but in a > different, correct, way, and I have spotted three more inconsistencies > within doc/src/sgml/datatype.sgml in the zone for timestamps. Right, I omitted them to avoid churn since they are using correctly, just in a different way from the rest of the docs. I'll leave the call whether they should be included for consistency sake to you. > With everything I found on top of your stuff, I finish with the > attached. Does it look fine to you? +1, thanks for picking it up! cheers ./daniel
CHECK constraints - order of evaluation
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/9.6/ddl-constraints.html Description: I think the information about the "order of execution" when checking CHECK constraints when inserting or updating records is missing in the documentation. There seems to be an old e-mail thread on the topic, however, there is no information on whether the patch submitted was already merged and if so, in which version of PostgreSQL. I also suggest it would be good to point out in the documentation how the order of CHECK constraints is created when there are more column CHECK constraints and table CHECK constraints (i.e. in mixed cases) or whether only the name of the constraint is relevant when it comes to it, not its type (column/table). Thank you very much in advance. Kindest regards, Ľudovít
Re: CHECK constraints - order of evaluation
On Thu, May 14, 2020 at 2:30 AM PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/9.6/ddl-constraints.html > Description: > > I think the information about the "order of execution" when checking CHECK > constraints when inserting or updating records is missing in the > documentation. Check constraints require immutable functions and do not have side effects. The order of their execution is immaterial and thus not documented. The server is free to do whatever it wishes whenever it wishes and users should not depend on any specific observed order in their usage (I don't believe we actually say to avoid depending upon undocumented behavior but that is the general guideline or working with systems). David J.
Re: Missing comma?
On 2020-05-14 03:07, Michael Paquier wrote:
On Wed, May 13, 2020 at 05:17:43PM +0300, Marina Polyakova wrote:
in my opinion it's a little unclear what "or default" means at the
end,
because the comma is used to separate enumeration elements ("d =
default
<...>, n = nothing, f = all columns, i = index <...>") and inside the
element description ("i = index with indisreplident set, or default").
Therefore here is an additional patch from me to clarify this place,
thanks
to Alexander Lakhin for help.
Yes, I agree that this last "or default" in the docs does not make
much sense, because we always enforce REPLICA_IDENTITY_NOTHING if
there is no replica identity.
This looks like a shortened version of a comment from
src/include/catalog/pg_class.h:
/*
* an explicitly chosen candidate key's columns are used as replica
identity.
* Note this will still be set if the index has been dropped; in that
case it
* has the same meaning as 'd'.
*/
#define REPLICA_IDENTITY_INDEX'i'
diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
index
02ddebae99d98110a8dd290dd4cb0c980adf7984..034a08f80ea4269f131e7e1383ba482fd76d9344
100644
--- a/doc/src/sgml/catalogs.sgml
+++ b/doc/src/sgml/catalogs.sgml
@@ -1936,7 +1936,7 @@ SCRAM-SHA-256$:&l
d = default (primary key, if any),
n = nothing,
f = all columns,
- i = index with
indisreplident set, or default
+ i = index with
indisreplident set (if any)
And you don't need the ("if any") either here, no?
REPLICA_IDENTITY_INDEX means that we have an index associated with the
replica identity so it seems to me that this last part can just be
removed.
I tried to save information for cases when the index is dropped as in
the code comment (see above) and the function RelationGetIndexList
(where IIUC we check if this index exists):
if (replident == REPLICA_IDENTITY_DEFAULT && OidIsValid(pkeyIndex))
relation->rd_replidindex = pkeyIndex;
else if (replident == REPLICA_IDENTITY_INDEX &&
OidIsValid(candidateIndex))
relation->rd_replidindex = candidateIndex;
else
relation->rd_replidindex = InvalidOid;
Perhaps it will be useful for some users to know that relreplident = i
does not mean that the required index exists (as in default case)?..
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Re: TLS docs fixes for
On Thu, May 14, 2020 at 09:38:09AM +0200, Daniel Gustafsson wrote: > On 14 May 2020, at 04:17, Michael Paquier wrote: >> With everything I found on top of your stuff, I finish with the >> attached. Does it look fine to you? > > +1, thanks for picking it up! Thanks, I have applied the previous version then as of 07451e1. -- Michael signature.asc Description: PGP signature
Re: Missing comma?
On Thu, May 14, 2020 at 06:30:38PM +0300, Marina Polyakova wrote: > Perhaps it will be useful for some users to know that relreplident = i does > not mean that the required index exists (as in default case)?.. Yeah, that feels incomplete and I think that it would be good to close the gap here, as the user has no way to guess how things work now just by looking at the docs. What about switching your suggestion of "(if any)" to be "(same as default if the index used got dropped)"? -- Michael signature.asc Description: PGP signature
