The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/17/rowtypes.html
Description:
The doc has example:
All of these ORDER BY clauses specify the row's composite value, resulting
in sorting the rows according to the rules described in Section 9
Hello,
I think you are saying that 'statement' in the documentation shall mean
'SQL statement' and not 'the time of receipt of the latest command message
from the client'.
I also think that statement_timestamp() will keep its name, even though the
name can be seen as misleading by some.
I theref
Laurenz Albe writes:
> On Sun, 2025-07-13 at 17:32 -0700, David G. Johnston wrote:
>> We seldom if ever resort to including descriptions involving the fe/be
>> protocol
>> in the SQL portion of the documentation - rightly considering (IMO) those to
>> be
>> implementation details (e.g., we don't
"David G. Johnston" writes:
> I dislike the word message.
> It would be nice if we could say/document: Command means top-level SQL;
> Statement references a sub-component of a command.
I think there are enough places where we use those words
interchangeably that it would be very difficult to get
"David G. Johnston" writes:
> Cannot readily test this presently but I wonder what the following produces:
> psql -c "begin; select statement_timestamp(), transaction_timestamp();
> select statement_timestamp(), transaction_timestamp(); commit; begin;
> select statement_timestamp(), transaction_t
"David G. Johnston" writes:
> Ok. That explains why "statement_timestamp() and transaction_timestamp()
> return the same value during the first command of a transaction," isn't
> just stating the obvious. transaction_timestamp() literally returns the
> value statement_timestamp().
Right. I'm t
On Mon, Jul 14, 2025 at 9:08 AM Tom Lane wrote:
> "David G. Johnston" writes:
> > Cannot readily test this presently but I wonder what the following
> produces:
>
> > psql -c "begin; select statement_timestamp(), transaction_timestamp();
> > select statement_timestamp(), transaction_timestamp();
On Sunday, July 13, 2025, PG Doc comments form
wrote:
>
> I suggest to extend the example to sort results by first composite type and
> then by the second:
> SELECT * FROM invertory_type t, inventory_item c ORDER BY (c.name,
> c.supplier_id, c.price), (t.name, t.value);
>
> Though I did not check
On Monday, July 14, 2025, Tom Lane wrote:
> "David G. Johnston" writes:
> > If we accept that we use the words statement and command interchangeably
> > then the sole remaining use of command here sticks out because now we
> have
> > to explain why commands are different from statements. I'd ra
"David G. Johnston" writes:
> If we accept that we use the words statement and command interchangeably
> then the sole remaining use of command here sticks out because now we have
> to explain why commands are different from statements. I'd rather just
> remove the parenthetical. It's poorly cla
On Mon, Jul 14, 2025 at 8:45 AM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> I would then add an example In 53.2.2.1 showing this happening using "psql
> -c"
>
>
Cannot readily test this presently but I wonder what the following produces:
psql -c "begin; select statement_timestamp(),
On Mon, Jul 14, 2025 at 8:17 AM Tom Lane wrote:
> Laurenz Albe writes:
> > On Sun, 2025-07-13 at 17:32 -0700, David G. Johnston wrote:
> >> We seldom if ever resort to including descriptions involving the fe/be
> protocol
> >> in the SQL portion of the documentation - rightly considering (IMO)
>
On Mon, Jul 14, 2025 at 10:09 AM Tom Lane wrote:
> "David G. Johnston" writes:
> > Ok. That explains why "statement_timestamp() and transaction_timestamp()
> > return the same value during the first command of a transaction," isn't
> > just stating the obvious. transaction_timestamp() literall
On 2025/06/18 6:53, Robert Treat wrote:
I think the more cases where you document this behavior (and I do like
the idea of documenting it for total_vacuum_time), the more one is
likely to think that places where it is not documented operate
differently. To that end, I think documenting it for
n
On Mon, 2025-07-14 at 13:09 -0400, Tom Lane wrote:
> "David G. Johnston" writes:
> > Ok. That explains why "statement_timestamp() and transaction_timestamp()
> > return the same value during the first command of a transaction," isn't
> > just stating the obvious. transaction_timestamp() literall
On Tue, 2025-07-15 at 01:51 +0900, Fujii Masao wrote:
>
> On 2025/06/18 6:53, Robert Treat wrote:
> > I think the more cases where you document this behavior (and I do like
> > the idea of documenting it for total_vacuum_time), the more one is
> > likely to think that places where it is not docume
16 matches
Mail list logo
