Dear Michael,
> Thanks, I've applied some slight tweaks, and applied the result down
> to v17, leaving the heap_update point alone.
Thanks, I confirmed your commit on HEAD and LGTM.
Best regards,
Hayato Kuroda
FUJITSU LIMITED
On Mon, Apr 21, 2025 at 12:10:51PM +, Hayato Kuroda (Fujitsu) wrote:
> Thanks for suggesting them. ISTM, you are correct. PSA updated version.
Thanks, I've applied some slight tweaks, and applied the result down
to v17, leaving the heap_update point alone.
--
Michael
signature.asc
Descriptio
Dear Michael,
> > I also feel just converting lower case is not good. The point seems to
> > locate in
> > the end-of-transaction callback and it accepts invalidation messages. Based
> > on
> the
> > fact, how about "inval-process-invalidation-messages"?
> > 0002 did simple replacements of these
On Mon, Apr 14, 2025 at 12:36:20PM +, Hayato Kuroda (Fujitsu) wrote:
> I also feel just converting lower case is not good. The point seems to locate
> in
> the end-of-transaction callback and it accepts invalidation messages. Based
> on the
> fact, how about "inval-process-invalidation-messag
Dear Aleksander,
> ```
> - their own code using the same macro.
> + their own code using the same macro. The name of injection points must
> be
> + lower characters, and dashes must separate its terms.
> ```
>
> Perhaps "must" is a too strong statement. I suggest something like:
>
Hi,
> Naming rule of points is not determined yet, but most of them have lower cases
> and each term are divided by dash "-". I think this is a good chance to
> formally
> clarify it. PSA adding the description.
>
> I was confused the correct place for the description. I added at the end of
> fi
Dear Fujii-san,
> Unless there are any objections, I plan to push your patch with
> the following commit message and back-patch it to all supported versions.
...
Thanks for updating the commit message. LGTM.
Best regards,
Hayato Kuroda
FUJITSU LIMITED
On 2025/03/21 10:07, Hayato Kuroda (Fujitsu) wrote:
Dear Fujii-san,
Unless there are any objections, I plan to push your patch with
the following commit message and back-patch it to all supported versions.
...
Thanks for updating the commit message. LGTM.
I've committed the patch with th
On 2025/03/19 11:07, Hayato Kuroda (Fujitsu) wrote:
Dear Fujii-san,
Why was this restriction removed? If there was a past discussion about it,
could you share the details?
More properly, pg_drop_replication_slot() has been introduced since PG9.4, and
old
documents did not have the descrip
Dear Fujii-san,
> Why was this restriction removed? If there was a past discussion about it,
> could you share the details?
More properly, pg_drop_replication_slot() has been introduced since PG9.4, and
old
documents did not have the description. The description has been added while
developing P
On 2025/03/18 17:46, Hayato Kuroda (Fujitsu) wrote:
Dear hackers,
While considering another thread, I found the $SUBJECT. Attached patch fixes it.
Thanks for the patch!
Documentation says:
```
pg_drop_replication_slot ( slot_name name ) → void
Drops the physical or logical replication
Michael Paquier writes:
> On Mon, Feb 05, 2024 at 03:59:27PM +, Dagfinn Ilmari Mannsåker wrote:
>> I just noticed that a couple of places in the docs spell I/O as IO or
>> even io when not referring to literal table/view/column names or values
>> therein. Here's a patch to fix them.
>
> Make
On Mon, Feb 05, 2024 at 03:59:27PM +, Dagfinn Ilmari Mannsåker wrote:
> I just noticed that a couple of places in the docs spell I/O as IO or
> even io when not referring to literal table/view/column names or values
> therein. Here's a patch to fix them.
Makes sense to me to be consistent in
2023年12月28日(木) 15:37 Michael Paquier :
>
> On Thu, Dec 28, 2023 at 01:55:27PM +0900, Ian Lawrence Barwick wrote:
> > 2023年6月7日(水) 9:08 Ian Lawrence Barwick :
> >> The alternative v2 patch adds this to this list of OIDs, and also
> >> formats it as an
> >> SGML list, which IMHO is easier to read.
>
On Thu, Dec 28, 2023 at 01:55:27PM +0900, Ian Lawrence Barwick wrote:
> 2023年6月7日(水) 9:08 Ian Lawrence Barwick :
>> The alternative v2 patch adds this to this list of OIDs, and also
>> formats it as an
>> SGML list, which IMHO is easier to read.
>>
>> Looks like this has been missing since 9.3.
>
2023年6月7日(水) 9:08 Ian Lawrence Barwick :
>
> Hi
>
> Here:
>
> https://www.postgresql.org/docs/current/fdw-functions.html
>
> the enumeration of OIDs which might be passed as the FDW validator function's
> second argument omits "AttributeRelationId" (as passed when altering
> a foreign table's col
Re: Tom Lane
> Christoph Berg writes:
> > I didn't understand the current wording of the NOTES section in
> > psql(1) on which major versions psql is compatible with, so here's a
> > patch to make that more explicit.
>
> This seems both very repetitive and incorrect in detail.
Meh, I tried to pr
Christoph Berg writes:
> I didn't understand the current wording of the NOTES section in
> psql(1) on which major versions psql is compatible with, so here's a
> patch to make that more explicit.
This seems both very repetitive and incorrect in detail.
Some operations will work fine with older se
On Fri, Aug 19, 2022 at 12:04:54PM -0400, Bruce Momjian wrote:
> You are right about the above to changes. The existing syntax shows
> FROM/IN is only possible if a direction is specified, while
> src/parser/gram.y says that FROM/IN with no direction is supported.
>
> I plan to apply this second
On Fri, Oct 15, 2021 at 12:52:48PM -0400, rir wrote:
>
> In pgsql-docs, this patch has been recommended to you.
>
> Lacking consensus and so not included is the the deletion of
> comments pointing between the ref/MOVE and FETCH files. These
> were of the form:
>
>
Sorry, I am just looking
> On 25 Mar 2022, at 13:59, Dagfinn Ilmari Mannsåker wrote:
>
> Daniel Gustafsson writes:
>
>>> On 24 Mar 2022, at 19:34, Dagfinn Ilmari Mannsåker
>>> wrote:
>>
>>> I just spotted an unnecessarily gendered example involving a 'salesmen'
>>> table in the UPDATE docs. Here's a patch that chang
Daniel Gustafsson writes:
>> On 24 Mar 2022, at 19:34, Dagfinn Ilmari Mannsåker wrote:
>
>> I just spotted an unnecessarily gendered example involving a 'salesmen'
>> table in the UPDATE docs. Here's a patch that changes that to
>> 'salespeople'.
>
> No objections to changing that, it's AFAICT t
> On 24 Mar 2022, at 19:34, Dagfinn Ilmari Mannsåker wrote:
> I just spotted an unnecessarily gendered example involving a 'salesmen'
> table in the UPDATE docs. Here's a patch that changes that to
> 'salespeople'.
No objections to changing that, it's AFAICT the sole such usage in the docs.
>
On Fri, 2021-10-15 at 12:52 -0400, rir wrote:
>
> In pgsql-docs, this patch has been recommended to you.
>
> Lacking consensus and so not included is the the deletion of
> comments pointing between the ref/MOVE and FETCH files. These
> were of the form:
>
>
Just for context: the -docs thr
On Mon, Jun 21, 2021 at 4:41 PM Brar Piening wrote:
>
> Amit Kapila schrieb:
> > On Mon, Jun 21, 2021 at 4:13 PM Brar Piening wrote:
> >> Amit Kapila wrote:
> >> After looking at the docs once again I have another minor amendment (new
> >> patch attached).
> >>
> > +The value of t
Amit Kapila schrieb:
On Mon, Jun 21, 2021 at 4:13 PM Brar Piening wrote:
Amit Kapila wrote:
After looking at the docs once again I have another minor amendment (new
patch attached).
+The value of the column, eiter in binary or in text format.
Typo. /eiter/either
Fixed - tha
On Mon, Jun 21, 2021 at 4:13 PM Brar Piening wrote:
>
> Amit Kapila wrote:
> >
> After looking at the docs once again I have another minor amendment (new
> patch attached).
>
+The value of the column, eiter in binary or in text format.
Typo. /eiter/either
--
With Regards,
Amit
Amit Kapila wrote:
On Mon, Jun 21, 2021 at 12:26 PM Brar Piening wrote:
Hello Hackers,
while amending Npgsql to account for the Logical Streaming Replication
Protocol changes in PostgreSQL 14 I stumbled upon two documentation
inaccuracies in the Logical Replication Message Formats documentation
On Mon, Jun 21, 2021 at 12:26 PM Brar Piening wrote:
>
> Hello Hackers,
> while amending Npgsql to account for the Logical Streaming Replication
> Protocol changes in PostgreSQL 14 I stumbled upon two documentation
> inaccuracies in the Logical Replication Message Formats documentation
> (https://
On Sat, Mar 06, 2021 at 06:12:50PM +0100, Magnus Hagander wrote:
> On Tue, Feb 23, 2021 at 7:19 AM Robert Treat wrote:
> > On Thu, Dec 31, 2020 at 10:05 AM Michael Banck
> > wrote:
> > > Am Montag, den 28.12.2020, 20:41 +0900 schrieb Masahiko Sawada:
> > > > On Sat, Nov 28, 2020 at 7:50 AM Michae
On Tue, Feb 23, 2021 at 7:19 AM Robert Treat wrote:
>
> On Thu, Dec 31, 2020 at 10:05 AM Michael Banck
> wrote:
> >
> > Hi,
> >
> > Am Montag, den 28.12.2020, 20:41 +0900 schrieb Masahiko Sawada:
> > > On Sat, Nov 28, 2020 at 7:50 AM Michael Banck
> > > wrote:
> > > > https://www.postgresql.org
On Thu, Dec 31, 2020 at 10:05 AM Michael Banck
wrote:
>
> Hi,
>
> Am Montag, den 28.12.2020, 20:41 +0900 schrieb Masahiko Sawada:
> > On Sat, Nov 28, 2020 at 7:50 AM Michael Banck
> > wrote:
> > > https://www.postgresql.org/docs/current/default-roles.html mentions the
> > > "Administrator" sever
Hi,
Am Montag, den 28.12.2020, 20:41 +0900 schrieb Masahiko Sawada:
> On Sat, Nov 28, 2020 at 7:50 AM Michael Banck
> wrote:
> > https://www.postgresql.org/docs/current/default-roles.html mentions the
> > "Administrator" several times, but does not specify it further. I
> > understand that it is
Hi Michael,
On Sat, Nov 28, 2020 at 7:50 AM Michael Banck wrote:
>
> Hi,
>
> https://www.postgresql.org/docs/current/default-roles.html mentions the
> "Administrator" several times, but does not specify it further. I
> understand that it is mentioned elsewhere [1], but I think it would be
> benef
Michael Paquier writes:
> On Wed, Jul 29, 2020 at 03:06:58PM +0900, Michael Paquier wrote:
>> This is actually a bug fix, because we include in the docs some
>> incorrect information, so it should be backpatched. If there are no
>> objections, I'll take care of that.
>
> And done.
Thanks!
- il
On Wed, Jul 29, 2020 at 03:06:58PM +0900, Michael Paquier wrote:
> This is actually a bug fix, because we include in the docs some
> incorrect information, so it should be backpatched. If there are no
> objections, I'll take care of that.
And done.
--
Michael
signature.asc
Description: PGP sign
On Tue, Jul 28, 2020 at 12:21:29PM +0100, Dagfinn Ilmari Mannsåker wrote:
> When partitioned index support was added in veresion 11, the pg_inherits
> docs missed the memo and still only say it describes table inheritance.
> The attached patch adds mentions of indexes too, and notes that they can
>
"Daniel Verite" writes:
> Tom Lane wrote:
>> As of HEAD, it's impossible to select latex output format
>> at all:
>> regression=# \pset format latex
>> \pset: ambiguous abbreviation "latex" matches both "latex" and
>> "latex-longtable"
> Oops!
>> We could fix that by adding a special case
Tom Lane wrote:
> As of HEAD, it's impossible to select latex output format
> at all:
>
> regression=# \pset format latex
> \pset: ambiguous abbreviation "latex" matches both "latex" and
> "latex-longtable"
Oops!
> We could fix that by adding a special case to accept an exact match
> im
"Daniel Verite" writes:
> Tom Lane wrote:
>> Pushed. (I simplified the code a bit by using just one state variable,
>> and also made the error message more verbose.)
> Thanks!
I noticed while poking at the csv patch that we'd outsmarted ourselves
with this one. As of HEAD, it's impossible to s
Tom Lane wrote:
> Pushed. (I simplified the code a bit by using just one state variable,
> and also made the error message more verbose.)
Thanks!
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite
"Daniel Verite" writes:
> Tom Lane wrote:
>> Ugh. Should we not fix the code so that it complains if there's
>> not a unique match? I would bet that the code was also written
>> on the assumption that any abbrevation must be unique.
> Here's a patch making "\pset format" reject ambiguous
Tom Lane wrote:
> > but "one letter is enough" is not true since 9.3 that added
> > "latex-longtable" sharing the same start as "latex", and then
> > 9.5 added "asciidoc" with the same first letter as "aligned".
>
> Yeah, that text has clearly outstayed its welcome.
>
> > When a non-uni
On Tue, Nov 06, 2018 at 06:18:37PM +0100, Daniel Verite wrote:
> In both cases using abbreviations in scripts is not a great
> idea. Anyway I will look into the changes required in do_pset to
> implement the error on multiple matches, if that's the preferred
> behavior.
You would also break the co
Tom Lane wrote:
> > When a non-unique abbreviation is used, psql uses the first
> > match in an arbitrary order defined in do_pset() by
> > a cascade of pg_strncasecmp().
>
> Ugh. Should we not fix the code so that it complains if there's
> not a unique match? I would bet that the code
"Daniel Verite" writes:
> psql's documentation has this mention about output formats:
> "Unique abbreviations are allowed. (That would mean one letter is enough.)"
> but "one letter is enough" is not true since 9.3 that added
> "latex-longtable" sharing the same start as "latex", and then
> 9.5
On Fri, Aug 17, 2018 at 09:57:08AM +0200, Paul Bonaud wrote:
> I shared the pach in plain textin the email body and figured out that
> all other patches are submitted as an attachement. Sorry for that, here
> is the patch attached to this email.
Patch applied through 9.5, where the "match" text fi
I shared the pach in plain textin the email body and figured out that
all other patches are submitted as an attachement. Sorry for that, here
is the patch attached to this email.
Thanks!
Paul
On 17/08/18 01:21, Paul Bonaud wrote:
> Hello,
>
> Please find below a submission of a patch to the Post
Hi Alexander,
On 2018/08/10 20:27, Alexander Korotkov wrote:
On Fri, Aug 10, 2018 at 1:37 PM Alexander Korotkov
wrote:
On Fri, Aug 10, 2018 at 6:24 AM Tatsuro Yamada
wrote:
Attached patch for fixing documents of "61.2. Index Access Method Functions" and
"61.6. Index Cost Estimation Function
On Fri, Aug 10, 2018 at 1:37 PM Alexander Korotkov
wrote:
> On Fri, Aug 10, 2018 at 6:24 AM Tatsuro Yamada
> wrote:
> >
> > Attached patch for fixing documents of "61.2. Index Access Method
> > Functions" and
> > "61.6. Index Cost Estimation Functions".
> >
> > I added a variable "double *indexP
Hi!
On Fri, Aug 10, 2018 at 6:24 AM Tatsuro Yamada
wrote:
>
> Attached patch for fixing documents of "61.2. Index Access Method Functions"
> and
> "61.6. Index Cost Estimation Functions".
>
> I added a variable "double *indexPages" introduced by commit 5262f7a4f to the
> documents and
> also ad
On 2018-Aug-01, Fabien COELHO wrote:
> Hello Daniel,
>
> > Patch applies cleanly, doc build ok, works for me.
>
> I have added it to the next CF and marked it as ready.
Pushed, thanks.
I applied it to 11 too. I would have added it even further back, but it
didn't apply cleanly.
How about an
Hello Daniel,
Patch applies cleanly, doc build ok, works for me.
I have added it to the next CF and marked it as ready.
--
Fabien.
Why referencing only create_view, but not delete, insert, update, select
or select_into where RECURSIVE is also used?
ISTM that at least the select page should be referenced, I'm less sure of
the others because there it appears only in the synopsys.
Looking at other occurrences of , it seems
Fabien COELHO wrote:
> Why referencing only create_view, but not delete, insert, update, select
> or select_into where RECURSIVE is also used?
>
> ISTM that at least the select page should be referenced, I'm less sure of
> the others because there it appears only in the synopsys.
Looki
Hello Daniel,
I've noticed that RECURSIVE as a term is not in the index, and thought
it should be. PFA a patch to add it with references to WITH queries and
CREATE VIEW.
Sounds reasonable.
Why referencing only create_view, but not delete, insert, update, select
or select_into where RECURS
56 matches
Mail list logo
