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 Sat, Apr 26, 2025 at 5:50 AM PG Doc comments form
wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/17/dml-returning.html
> Description:
>
> Today I found a pretty special use-case for the "RETURNING" functionality,
> which I
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
"David G. Johnston" writes:
> (Likewise, the system-username regexp can contain more than one capture -
> which are only available later in the system-username regexp - though again
> it seems unlikely anyone is going to use that feature in this context.)
Yeah, I was thinking about that while wor
On Sun, Jul 13, 2025 at 11:30 AM Tom Lane wrote:
> I figured out how to make the 003_peer.pl tests for \1 less
> hacky, and pushed that. Here's a proposed patch for the
> documentation side of things, including your suggestion to
> make pg_ident.conf.sample match up better.
>
>
Thanks. My goal
I figured out how to make the 003_peer.pl tests for \1 less
hacky, and pushed that. Here's a proposed patch for the
documentation side of things, including your suggestion to
make pg_ident.conf.sample match up better.
regards, tom lane
diff --git a/doc/src/sgml/client-aut
KES writes:
> I would prefer to remove the option from the configuration list
> instead of having it reset to empty string.
That is not the definition, and we'd be very unlikely to change
it to do that, because it would make no sense for built-in or
extension-defined settings.
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 Sunday, July 13, 2025, KES wrote:
> I suppose that DEFAULT syntax should be used to set setting to its default
> value. Eg.
> set_config( 'my.option', DEFAULT, false )
> This is clear what should happen here. Also this syntax will correspond to
> other places, eg. INSERT INTO xx (name) VALUES
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_timestamp() returns the
> start ti
I suppose that DEFAULT syntax should be used to set setting to its default value. Eg.set_config( 'my.option', DEFAULT, false )This is clear what should happen here. Also this syntax will correspond to other places, eg. INSERT INTO xx (name) VALUES (DEFAULT). Using NULL to set reset the value to the
I would prefer to remove the option from the configuration list instead of having it reset to empty string. Eg. set_config( 'my.option', NULL, false ) Having it to return the empty string cause differences in the behaviour when parameter is not recognized at all and when it setup to default. How to
15 matches
Mail list logo
