Laurenz Albe writes:
> This thread doesn't look like we're going to find a wording that will
> make everyone happy, but I believe that this patch is a clear improvement.
Pushed with the "command message" wording. Thanks for the discussion!
regards, tom lane
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 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 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
"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();
"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
e very difficult to get to a point of
consistently making the distinction. Moreover, the distinction isn't
important for most purposes. So I think the right route is to make
this para provide a self-contained description of what it's talking
about, rather than to reference a glossa
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)
>
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
d leave it to the reader to discover 'well that function's naming is a
bit unfortunate', but not elaborate on that in the documentation.
A bonus would be to define 'command message' in the glossary.
Side note: This is the SQL that I used to teach myself that
'statemen
On Sun, 2025-07-13 at 17:32 -0700, David G. Johnston wrote:
> On Sun, Jul 13, 2025 at 2:57 PM Tom Lane wrote:
> > ... so concretely, about like this?
I am fine with the patch as it is.
> We seldom if ever resort to including descriptions involving the fe/be
> protocol
> in the SQL portion of th
On Sun, Jul 13, 2025 at 2:57 PM Tom Lane wrote:
> ... so concretely, about like this?
>
>
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 even dir
... so concretely, about like this?
regards, tom lane
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 6b327d4fd81..ed30dbe7ccd 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -11244,13 +11244,13 @@ now()
CURRENT_TIMESTAMP, but is
Laurenz Albe writes:
> Perhaps the remark should say "protocol message" or "frontend-backend
> protocol message" to make clear that we are not talking about an
> SQL statement here.
Yeah, that seems like a good idea.
regards, tom lane
On Sun, 2025-07-13 at 11:27 -0400, Tom Lane wrote:
> Laurenz Albe writes:
> > After looking at the code, I guess what made Tom add the remark in commit
> > eaf8f312c754 was the fact that an SQL statement is not necessarily processed
> > in a single go: with the extended query protocol (see chapter
Laurenz Albe writes:
> After looking at the code, I guess what made Tom add the remark in commit
> eaf8f312c754 was the fact that an SQL statement is not necessarily processed
> in a single go: with the extended query protocol (see chapter 52.2.3),
> there is a "parse", a "bind" and an "execute" m
On Fri, 2025-07-11 at 10:34 +, PG Doc comments form wrote:
> the glossary (https://www.postgresql.org/docs/current/glossary.html) does
> not define 'statement' but a definition would be important to understand
> other chapters such as this sentence: "statement_timesta
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/17/glossary.html
Description:
Hello,
the glossary (https://www.postgresql.org/docs/current/glossary.html) does
not define 'statement' but a definition would be important to unders
On 2024-04-25 22:00 +0200, Alexander Lakhin wrote:
> 25.04.2024 12:24, Alvaro Herrera wrote:
> > On 2024-Apr-12, Erik Wienhold wrote:
> >
> > > There's this bug[1] in the DocBook XSLT stylesheets. Looks like the
> > > fix[2] landed in 1.79.2 (latest version on Arch,
> > Maybe one of these days we
Hello,
25.04.2024 12:24, Alvaro Herrera wrote:
On 2024-Apr-12, Erik Wienhold wrote:
There's this bug[1] in the DocBook XSLT stylesheets. Looks like the
fix[2] landed in 1.79.2 (latest version on Arch,
Maybe one of these days we should get going with the migration to
Docbook 5.x that Jürgen P
On 2024-Apr-25, Jürgen Purtz wrote:
> Great recommendation. I may have time in the second half of June to
> pursue the migration further. There is a performance problem, which
> possibly results from our XSLT script that optimizes the
> transformation-speed and works well in 4.x.
Maybe a way to
On 2024-04-25 15:40 +0200, Jürgen Purtz wrote:
> On 25.04.24 13:24, Jürgen Purtz wrote:
> >
> > On 25.04.24 11:24, Alvaro Herrera wrote:
> > > On 2024-Apr-12, Erik Wienhold wrote:
> > >
> > > > There's this bug[1] in the DocBook XSLT stylesheets. Looks like the
> > > > fix[2] landed in 1.79.2 (l
On 25.04.24 13:24, Jürgen Purtz wrote:
On 25.04.24 11:24, Alvaro Herrera wrote:
On 2024-Apr-12, Erik Wienhold wrote:
There's this bug[1] in the DocBook XSLT stylesheets. Looks like the
fix[2] landed in 1.79.2 (latest version on Arch,
Maybe one of these days we should get going with the mi
On 25.04.24 11:24, Alvaro Herrera wrote:
On 2024-Apr-12, Erik Wienhold wrote:
There's this bug[1] in the DocBook XSLT stylesheets. Looks like the
fix[2] landed in 1.79.2 (latest version on Arch,
Maybe one of these days we should get going with the migration to
Docbook 5.x that Jürgen Purtz p
On 2024-Apr-12, Erik Wienhold wrote:
> There's this bug[1] in the DocBook XSLT stylesheets. Looks like the
> fix[2] landed in 1.79.2 (latest version on Arch,
Maybe one of these days we should get going with the migration to
Docbook 5.x that Jürgen Purtz proposed.
https://postgr.es/m/21ed3fd9-90
On 2024-04-12 18:29 +0200, Anton Voloshin wrote:
> In REL_13_STABLE and above, generated HTML have a broken HTML: nested href="..."> tags for all links to glossary. Somehow, this results in
> duplicated tags on the https://www.postgresql.org/docs/
>
> Foun
Hello,
In REL_13_STABLE and above, generated HTML have a broken HTML: nested href="..."> tags for all links to glossary. Somehow, this results in
duplicated tags on the https://www.postgresql.org/docs/
Found by tab-navigating https://www.postgresql.org/docs/16/rowtypes.html
On 02.05.23 12:55, Daniel Gustafsson wrote:
On 2 May 2023, at 12:24, Alvaro Herrera wrote:
On 2023-May-02, Daniel Gustafsson wrote:
+
+ LSN
+
+
The other entries doesn't have a glossentry id
attribute set, is the use here related to the glossentry.show.acronym param?
I debated wi
> On 2 May 2023, at 12:24, Alvaro Herrera wrote:
>
> On 2023-May-02, Daniel Gustafsson wrote:
>
>> +
>> + LSN
>> +
>> +
>>
>> The other entries doesn't have a glossentry id
>> attribute set, is the use here related to the glossentry.show.acronym param?
>
> I debated with myself for 3
On 2023-May-02, Daniel Gustafsson wrote:
> +
> + LSN
> +
> +
>
> The other entries doesn't have a glossentry id
> attribute set, is the use here related to the glossentry.show.acronym param?
I debated with myself for 347d2b07fcc2 on whether to add id attribs to
entries. The only savi
> On 2 May 2023, at 09:05, Peter Eisentraut
> wrote:
>
> I wrote glossary entries for some terms I wanted to look up there but didn't
> find: "restartpoint" and "LSN". I put this together based on existing text.
> "LSN" was already in t
I wrote glossary entries for some terms I wanted to look up there but
didn't find: "restartpoint" and "LSN". I put this together based on
existing text. "LSN" was already in the acronyms list but I think it's
more appropriate in the gloss
On 2022/01/08 1:41, Tom Lane wrote:
Fujii Masao writes:
In glossary, the title of each term about process seems to consist of the process name and
"(process)", e.g., Checkpointer (process). But I found that "(process)" is missing for
the following three terms about
Fujii Masao writes:
> In glossary, the title of each term about process seems to consist of the
> process name and "(process)", e.g., Checkpointer (process). But I found that
> "(process)" is missing for the following three terms about process. Attached
> is
Hi,
In glossary, the title of each term about process seems to consist of the process name and
"(process)", e.g., Checkpointer (process). But I found that "(process)" is missing for
the following three terms about process. Attached is the patch to add "(process)"
On 2020-Jul-21, Jürgen Purtz wrote:
> - Added '(process)' to the two terms 'Autovacuum' and 'Stats Collector'
>
> - Removed link to himself in 'Logger (process)'
>
> - new term: Base Backup
Pushed. I was not courageous enough to include "base backup" in 13, so
that one's in master only, but th
On 19.06.20 19:10, Alvaro Herrera wrote:
Thanks for these fixes! I included all of these.
On 2020-Jun-19, Erik Rijkers wrote:
And one thing that I am not sure of (but strikes me as a bit odd):
there are several cases of
'are enforced unique'. Should that not be
'are enforced to be unique' ?
Thanks for these fixes! I included all of these.
On 2020-Jun-19, Erik Rijkers wrote:
> And one thing that I am not sure of (but strikes me as a bit odd):
> there are several cases of
> 'are enforced unique'. Should that not be
> 'are enforced to be unique' ?
I included this change too; I am no
On 2020-06-19 01:51, Alvaro Herrera wrote:
On 2020-Jun-16, Justin Pryzby wrote:
On Tue, Jun 16, 2020 at 08:09:26PM -0400, Alvaro Herrera wrote:
I noticed one typo:
'aggregates functions' should be
'aggregate functions'
And one thing that I am not sure of (but strikes me as a bit odd):
ther
t;/\1/' > orig
LC_COLLATE=en_US.UTF-8 sort orig > sorted
(Eliminating the tags is important, otherwise the sort uses the tags
themselves to disambiguate)
> One last question: The definition of "Data directory" reads "... A cluster's
> storage space comprises the da
ry" reads "... A
cluster's storage space comprises the data directory plus ..." and
'cluster' links to '"glossary-instance". Shouldn't it link to
"glossary-db-cluster"?
--
Jürgen Purtz
diff --git a/doc/src/sgml/glossary.sgml b/doc
> The base directory on the filesystem of a
> server that contains
> all
> - data files and subdirectories associated with an
> - instance (with the
> - exception of linkend="glossary-tablespace">tablespaces).
> + data files and subdi
On 2020-Jun-09, Jürgen Purtz wrote:
> Can you agree to the following definitions? If no, we can alternatively
> formulate for each of them: "Under discussion - currently not defined". My
> proposals are inspired by chapter 2.2 Concepts: "Tables are grouped into
> databases, and a collection of dat
On 17.05.20 17:28, Alvaro Herrera wrote:
I think the terms under discussion are just
* cluster
* instance
* server
Despite the short period of its existence the glossary achieved some
importance, see:
https://www.postgresql.org/message-id/b8e12875ebec9e6d3107df5fa1129e1e%40postgrespro.ru
On Wed, 2020-05-20 at 13:17 +0200, Jürgen Purtz wrote:
> > FWIW, I feel somewhat like Alvaro on that point; I use those terms
> > synonymously,
> > perhaps distinguishing between a "started cluster" and a "stopped cluster".
> > After all, "cluster" refers to "a cluster of databases", which are the
On 19.05.20 08:17, Laurenz Albe wrote:
On Mon, 2020-05-18 at 18:08 +0200, Jürgen Purtz wrote:
cluster/instance: PG (mainly) consists of a group of processes that commonly
act on shared buffers. The processes are very closely related to each other
and with the buffers. They exist altogether or no
On 2020-05-19 08:17, Laurenz Albe wrote:
The term "cluster" is unfortunate, because to most people it suggests a group of
machines, so the term "instance" is better, but that ship has sailed long ago.
I don't see what would stop us from renaming some things, with some care.
--
Peter Eisentraut
I think there needs to be a careful analysis of the language and a formal
effort to stabilise it for the future.
In the context of, say, an Oracle T series, which is partitioned into
multiple domains (virtual machines) in it, each
of these has multiple CPUs, and can run an instance of the OS which
On Mon, 2020-05-18 at 18:08 +0200, Jürgen Purtz wrote:
> cluster/instance: PG (mainly) consists of a group of processes that commonly
> act on shared buffers. The processes are very closely related to each other
> and with the buffers. They exist altogether or not at all. They use a common
> initia
On 17.05.20 17:28, Alvaro Herrera wrote:
On 2020-May-17, Erik Rijkers wrote:
On 2020-05-17 08:51, Alvaro Herrera wrote:
I don't think that's the general understanding of those terms. For all
I know, they*are* synonyms, and there's no specific term for "the
fluctuating objects" as you call th
On Thu, 2020-01-02 at 21:24 +, PG Doc comments form wrote:
> Page: https://www.postgresql.org/docs/12/creating-cluster.html
> Description:
>
> It would be great to have a glossary as an appendix, to define concepts such
> as cluster, schema, tablespace, database.
Does the in
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/12/creating-cluster.html
Description:
It would be great to have a glossary as an appendix, to define concepts such
as cluster, schema, tablespace, database.
55 matches
Mail list logo
