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 versio
> > 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".
>
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/ap
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
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_aud
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 insert
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:
>
It appears that in With-queries (CTE) the ON CASCADE DELETE deletions
happen at the very end of the entire statement. I have two questions about
this:
(1) Is this a correct observation?
(2) Is this intentional behavior, or only an accident of the implementation?
I can't find anything in the docs
> The sub-statements in WITH are executed concurrently
That much I did get from the docs. Given each sub-statement is qualified
by the RETURNING results of the previous one, that should at least
guarantee the completeness of each query regardless of the order in which
individual rows are affect
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 se
On Thu, Mar 20, 2025 at 7:08 AM Kirk Parker wrote:
>
> On Thu, Mar 20, 2025 at 2:46 AM PG Doc comments form <
> nore...@postgresql.org> wrote:
>
>> The following documentation comment has been logged on the website:
>>
>> Page: https://www.postgr
On Tue, Mar 11, 2025, 02:37 PG Doc comments form
wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/17/tutorial-fk.html
> Description:
>
> While going through the documentation in a sequential manner, attempting to
> create TABLE
On Thu, Mar 20, 2025 at 2:46 AM PG Doc comments form
wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/17/functions-json.html
> Description:
>
> On the manual page
> https://www.postgresql.org/docs/current/functions-json.html, i
13 matches
Mail list logo
