Re: Update documentation page for translators
> On 22 Oct 2021, at 13:12, PG Doc comments form wrote: > > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/11/nls-translator.html > Description: > > In the documentation for translators > (https://www.postgresql.org/docs/11/nls-translator.html) it is mentioned to > use any text editor for translating .po files. It can be very error prone > with regular text editors, especiially for non-tech people such as > translators. I think this makes sense, having done some translation work myself I agree that the PO editors out there can help quite a bit. Now, I'm sure anyone interested is perfectly capable of Googling, but since this chapter is there to help potential or new contributors I think it's fine to lower the bar and be a bit more verbose. I don't feel like linking to any specific tool though, so I just added a small sentence to indicate that options exist, and that we don't necessarily require anyone to use a text editor. CC:ing developers who have spent time with translations for input. -- Daniel Gustafsson https://vmware.com/ translations.diff Description: Binary data
\dp privileges "decoder" dropped in v12 of docs
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/13/sql-grant.html
Description:
Hello, I'm wondering why this version of the GRANT doc has the \dp privilege
definitions - https://www.postgresql.org/docs/9.3/sql-grant.html - but it's
no longer available in v13 of the docs, which i'm actually trying to use -
https://www.postgresql.org/docs/13/sql-grant.html
It seems that the section that has all of the definitions of the "privilege"
letters was dropped in v12. Was that just an oversight? Where can I find
that info nowadays?
To clarify, the section I'm talking about is this one:
---snip---
The entries shown by \dp are interpreted thus:
rolename= -- privileges granted to a role
= -- privileges granted to PUBLIC
r -- SELECT ("read")
w -- UPDATE ("write")
a -- INSERT ("append")
d -- DELETE
D -- TRUNCATE
x -- REFERENCES
t -- TRIGGER
X -- EXECUTE
U -- USAGE
C -- CREATE
c -- CONNECT
T -- TEMPORARY
arwdDxt -- ALL PRIVILEGES (for tables, varies for other objects)
* -- grant option for preceding privilege
/ -- role that granted this privilege
---snip---
Thanks!
Inger
RE: text fields and performance for ETL
Dear Moderators, with this approach, why don't you eliminate char and varchar then ? Thanks for thinking over. BR Grega -Original Message- From: Laurenz Albe Sent: Saturday, November 6, 2021 6:28 AM To: Bruce Momjian ; David G. Johnston Cc: Grega Jesih ; Tom Lane ; Pg Docs Subject: Re: text fields and performance for ETL On Fri, 2021-11-05 at 11:27 -0400, Bruce Momjian wrote: > On Fri, Nov 5, 2021 at 07:32:12AM -0700, David G. Johnston wrote: > > On Friday, November 5, 2021, Bruce Momjian wrote: > > > > > > > > > > Perhaps, right before the tip you quoted, something like that: > > > > > > If your use case requires a length limit on character data, > > or > > compliance > > > with the SQL standard is important, use "character varying". > > > Otherwise, you are usually better off with "text". > > > > I can support that if others think it is valuable. > > > > > > > > The motivating complaint is that we should be encouraging people to > > use varchar > > (4000) instead of text so external tools can optimize. If we are > > not going to do that I really don’t see the pointing in changing > > away from out current position of “only use text”. True length > > limit requirements for data are rare, and better done in constraints > > along with all other the other constraint that may exist for the > > data. I believe comments with respect to the SQL standard are already > > present and adequate. > > Agreed. +1, so let's leave it as it is. Yours, Laurenz Albe NOTICE - NOT TO BE REMOVED. This e-mail and any attachments are confidential and may contain legally privileged information and/or copyright material of Actual I.T. or third parties. If you are not an authorised recipient of this e-mail, please contact Actual I.T. immediately by return email or by telephone or facsimile on the above numbers. You should not read, print, re-transmit, store or act in reliance on this email or any attachments and you should destroy all copies of them.
Ltree pattern matching
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/12/ltree.html Description: In v12 ltree doc (I've not checked other versions) "The behavior of % is a bit complicated. It tries to match words rather than the entire label. For example foo_bar% matches foo_bar_baz but not foo_barbaz. If combined with *, prefix matching applies to each word separately, for example foo_bar%* matches foo1_bar2_baz but not foo1_br2_baz. I believe foo1 is in error (if I understood the operators), it should be foo. Regards T
Example of json_array_elements
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/12/functions-json.html
Description:
Maybe this example for json_array_elements is wrong?
select * from json_array_elements('[1,true, [2,false]]')
It seems to me that it should be
select * from json_array_elements('[[1,true], [2,false]]')
Thank you for this extraordinary documentation!
Re: \dp privileges "decoder" dropped in v12 of docs
On Thu, Nov 11, 2021 at 09:24:21PM +, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/13/sql-grant.html > Description: > > Hello, I'm wondering why this version of the GRANT doc has the \dp privilege > definitions - https://www.postgresql.org/docs/9.3/sql-grant.html - but it's > no longer available in v13 of the docs, which i'm actually trying to use - > https://www.postgresql.org/docs/13/sql-grant.html > > It seems that the section that has all of the definitions of the "privilege" > letters was dropped in v12. Was that just an oversight? Where can I find > that info nowadays? It was moved in this commit: commit afc4a78a30 Author: Tom Lane Date: Mon Dec 3 11:40:49 2018 -0500 Refactor documentation about privileges to centralize the info. Expand section 5.6 "Privileges" to include the full definition of each privilege type, and an explanation of aclitem privilege displays, along with some helpful summary tables. Most of this material came out of the GRANT reference page, although some of it is new. Adjust a bunch of links that were pointing to GRANT to point to 5.6. Fabien Coelho and Tom Lane, reviewed by Bradley DeJong Discussion: https://postgr.es/m/alpine.DEB.2.21.1807311735200.20743@lancre to a more appropriate place in the documentation: https://www.postgresql.org/docs/14/ddl-priv.html -- Bruce Momjian https://momjian.us EDB https://enterprisedb.com If only the physical world exists, free will is an illusion.
Re: Example of json_array_elements
> On 12 Nov 2021, at 13:18, PG Doc comments form wrote:
> Maybe this example for json_array_elements is wrong?
No, the example works as intended and yields the output in the documentation:
postgres=# select * from json_array_elements('[1,true, [2,false]]');
value
---
1
true
[2,false]
(3 rows)
Your proposal is also syntactically correct, but it's not what the author
intended when writing the example:
postgres=# select * from json_array_elements('[[1,true], [2,false]]');
value
---
[1,true]
[2,false]
(2 rows)
--
Daniel Gustafsson https://vmware.com/
Re: Ltree pattern matching
PG Doc comments form writes: > In v12 ltree doc (I've not checked other versions) > "The behavior of % is a bit complicated. It tries to match words rather than > the entire label. For example foo_bar% matches foo_bar_baz but not > foo_barbaz. If combined with *, prefix matching applies to each word > separately, for example foo_bar%* matches foo1_bar2_baz but not > foo1_br2_baz. > I believe foo1 is in error (if I understood the operators), it should be > foo. A quick test shows that the examples are correct as stated: contrib_regression=# select 'foo_bar_baz'::ltree ~ 'foo_bar%'::lquery; ?column? -- t (1 row) contrib_regression=# select 'foo_barbaz'::ltree ~ 'foo_bar%'::lquery; ?column? -- f (1 row) contrib_regression=# select 'foo1_bar2_baz'::ltree ~ 'foo_bar%*'::lquery; ?column? -- t (1 row) contrib_regression=# select 'foo1_br2_baz'::ltree ~ 'foo_bar%*'::lquery; ?column? -- f (1 row) I'd be the first to admit that this paragraph doesn't seem to measure up to our usual standards of clarity, but I'm not sure about what would be better wording. regards, tom lane
