Re: Possible spelling errors
On Wed, Jan 31, 2024, 23:10 PG Doc comments form
wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/16/auth-username-maps.html
> Description:
>
> Hello.
> I am not sure, but 'can be include directives' looks very strange to me:
> As for pg_hba.conf, the lines in this file can be include directives,
> following the same rules.
>
> I suppose it should be 'can include directives' or similar.
>
> Thanks.
>
Actually "include directive" here is a technical term and the entire phrase
is indeed correctly spelled.
("Include directive" is a line directing the configuration file processor
to read in the contents of the specified file as if it were literally
included here.)
Re: Clarify: default precision on timestamps is 6
On Fri, Oct 13, 2023 at 7:32 AM David G. Johnston < david.g.johns...@gmail.com> wrote: > On Friday, October 13, 2023, PG Doc comments form > wrote: > >> both of them round any precision >> beyond microseconds, and neither returns timestamps with greater precision >> than the value that was inserted. >> > > That is precisely what a no default with maximum of six means. If we say > the default is six that would imply storage of less precise values pads > significant zeros until there are six. > > David J. > > Not sure that last statement is correct. In 13 (only system I have access to at the moment) it doesn't look like casting to a precision greater than the value originally had causes any padding: some_system=# select CURRENT_TIMESTAMP(0)::timestamp(6) with time zone; current_timestamp 2023-10-13 17:19:00+00 (1 row) some_system=# select CURRENT_TIMESTAMP(1)::timestamp(6) with time zone; current_timestamp -- 2023-10-13 17:23:04.2+00 (1 row)
Re: Typo in PL/pgSQL trigger Example 43.4?
On Sat, Oct 7, 2023 at 1:22 PM Tom Lane wrote: > "David G. Johnston" writes: > > On Sat, Oct 7, 2023 at 11:11 AM Kirk Parker wrote: > >> INSERT INTO emp_audit SELECT 'D', now(), user, OLD.*; -- <= ARGUMENT IN > QUESTION > >> The emp_audit table has a column named 'userid', which in actual usage > >> (next-to-last line quoted) is populated by 'user' which seems undefined > in > >> the context. Was that intended to be 'current_user', or am I missing > >> something? > > > user is a valid pseudo-function: > > > https://www.postgresql.org/docs/current/functions-info.html#FUNCTIONS-INFO-SESSION > > Yeah, either way has the same result. However, I wonder if we should > change this example to use current_user for clarity. It does look > more like it's intended to be a variable or column reference than > a built-in function. > > Since the previous example on the page uses 'current_user' (which I suppose is why I didn't look further to see if 'user' was also a function), perhaps that would be a good idea. > >
Typo in PL/pgSQL trigger Example 43.4?
The PL/pgSQL page on triggers ( https://www.postgresql.org/docs/16/plpgsql-trigger.html ) contains the following example (I'm excerpting only the essential parts here): Example 43.4. A PL/pgSQL Trigger Function for Auditing ... CREATE TABLE emp_audit( operation char(1) NOT NULL, stamp timestamp NOT NULL, userid text NOT NULL, -- <= COLUMN IN QUESTION empnametext NOT NULL, salary integer ); CREATE OR REPLACE FUNCTION process_emp_audit() RETURNS TRIGGER AS $emp_audit$ BEGIN -- -- Create a row in emp_audit to reflect the operation performed on emp, -- making use of the special variable TG_OP to work out the operation. -- IF (TG_OP = 'DELETE') THEN INSERT INTO emp_audit SELECT 'D', now(), user, OLD.*; -- <= ARGUMENT IN QUESTION -- similar code with same issue follows for the other TG_OPs... The emp_audit table has a column named 'userid', which in actual usage (next-to-last line quoted) is populated by 'user' which seems undefined in the context. Was that intended to be 'current_user', or am I missing something?
Re: `pg_restore --if-exists` clarification
On Thu, Sep 28, 2023, 05:52 PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/16/app-pgrestore.html > Description: > > Good Morning, > > In the `pg_restore` docs > (https://www.postgresql.org/docs/current/app-pgrestore.html), > `--if-exists` > states that it is to > > > Use conditional commands (i.e., add an IF EXISTS clause) > > to drop database objects. This option is not valid unless > > --clean is also specified.", but not being a SQL expert, > > I'm having a hard time deciphering this. > > Suggestion: Would you consider adding the sentence (or something similar)? > > > "--clean makes pg_restore drop all objects first, > > and --if-exists prevents that non-existent objects > > cause a failure." > Source: https://stackoverflow.com/a/75136163/1498178 > > This is succinct, and tells exactly what one needs to know. Thank you and > have a great day! > > Appreciatively, > Attila > But "failure" is not what happens. If you read the part regarding --clean, you will see that it says: (Unless --if-exists is used, this might generate some *harmless error messages*, if any objects were not present in the destination database.) *[emphasis added]* with extra emphasis on the word "harmless" -- no failure is caused; the restore proceeds just fine. If anything were to change in this regard, it might be better to reconsider what we call the message (i.e.what language pg_restore emits in this scenario.) It's true, I suppose, in a literal sense that it's an error in that pg_restore couldn't drop a table when instructed to, where no such table exists. But pragmatically it doesn't matter, so why not reclassify this as a "warning" or a "notice"? --Kirk >
Re: Change "two" to "three" for decades of development in history
> > The following documentation comment has been logged on the website: > > > > Page: https://www.postgresql.org/docs/15/history.html > > Description: > > > > Hi, > > > > In https://www.postgresql.org/docs/current/history.html it is written > "With > > over two decades of development behind it". > > But since "The implementation of POSTGRES began in 1986" according to the > > same document, it should now be "With over three decades of development > > behind it". > > You are _totally_ correct. Attached patch applied back to PG 11. Seems > we will need to change this to "four" in a few years too. > > I don't suppose DocBook has macro and system-variable capabilities? That could provide a set-and-forget solution to this?
Nulls Not Distinct in Unique Indexes secton
The Unique Indexes section ( https://www.postgresql.org/docs/15/indexes-unique.html) does not mention the new NULLS [ NOT ] DISTINCT capability of indexes ( https://www.postgresql.org/docs/15/sql-createindex.html), and it probably should. Specifically, it has the exact wording from previous versions (emphasis added): When an index is declared unique, multiple table rows with equal indexed values are not allowed. *Null values are not considered equal*. We should consider adding "unless the NULLS NOT DISTINCT clause is used when creating the index", or something to that effect.
Implicit type conversion -- where documented?
I came across what seems like anomalous behavior regarding implicit conversion from a numeric type to text. You can write: select 3.1416 || '?'; and the number implicitly converts to text and concatenates just fine, but writing: select trim(3.1416); fails with an error message. This seems odd to me--in both cases a float literal is used in a context expecting text; in one case it implicitly converts, in the other it doesn't. *This brings up my real question*: are the details of this documented anywhere? Chapter 10 refers to ' implicit conversions' but I can't see anywhere that the docs explain the details of how it is done, that would explain the observed difference in behavior described above. Thanks!
