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 hackers,
This is a forked thread from [1].
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 descri
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
Dear hackers,
While considering another thread, I found the $SUBJECT. Attached patch fixes it.
Documentation says:
```
pg_drop_replication_slot ( slot_name name ) → void
Drops the physical or logical replication slot named slot_name. Same as
replication protocol command DROP_REPLICATION_SLOT.
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
Hi Hackers,
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.
- ilmari
>From ed5f9ce738dd6356d5d68e4cfed95d8d98d2cde5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Dagfin
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
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 column options).
Attached v1 patch adds this to this list of
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
Hi,
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.
Christoph
>From 89f947c215c679004e1f3fbf88751fe527e16f91 Mon Sep 17 00:00:00 2001
From: Christoph Berg
Date: Tue, 6 Sep 2022
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, Aug 19, 2022 at 10:42:45AM -0400, Bruce Momjian wrote:
> > Given that 'optional, optional' has no independent meaning from
> > 'optional'; it requires one to scan the entire set looking for
> > the non-optional embedded in the option. So no gain.
>
> I originally had the same reaction Mi
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 Sat, Oct 16, 2021 at 01:11:49PM -0400, rir wrote:
> On Sat, Oct 16, 2021 at 11:14:46AM +0900, Michael Paquier wrote:
> > On Fri, Oct 15, 2021 at 01:13:14PM -0400, rir wrote:
> > > This removes the outer square brackets in the create_database.sgml
> > > file's synopsis. In the command sysopses,
> 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.
>
Hi Hackers,
I just spotted an unnecessarily gendered example involving a 'salesmen'
table in the UPDATE docs. Here's a patch that changes that to
'salespeople'.
- ilmari
>From fde378ccd44c15f827a3c22630265f477d70d748 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Dagfinn=20Ilmari=20Manns=C3=A5ker?=
D
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 Sat, Oct 16, 2021 at 11:14:46AM +0900, Michael Paquier wrote:
> On Fri, Oct 15, 2021 at 01:13:14PM -0400, rir wrote:
> > This removes the outer square brackets in the create_database.sgml
> > file's synopsis. In the command sysopses, this is the only case
> > where an optional group contains on
On Fri, Oct 15, 2021 at 01:13:14PM -0400, rir wrote:
> This removes the outer square brackets in the create_database.sgml
> file's synopsis. In the command sysopses, this is the only case
> where an optional group contains only optional groups.
>
> CREATE DATABASE name
> -[ [ WITH ] [ OWNER [
This removes the outer square brackets in the create_database.sgml
file's synopsis. In the command sysopses, this is the only case
where an optional group contains only optional groups.
Rob
>From dc59127d1a739e6de0cff20086baf47d15837f0b Mon Sep 17 00:00:00 2001
From: rir
Date: Fri, 15 Oct 2021
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:
Thanks for the software,
Rob
>From 711a3299851cde9ce00b5ff2962f20cdc1796e72 Mon Sep 17 00:00
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://
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://www.postgresql.org/docs/devel/protocol-logicalrep-message-formats
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
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
beneficial to remind the reader on that page at least once that
"Administrators" incl
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
>
Hi Hackers,
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
not participate in multiple inheritance.
I don't know what the poli
Hi!
On Wed, Jul 8, 2020 at 4:43 AM Michael Paquier wrote:
> On Tue, Jul 07, 2020 at 06:36:10PM +0900, Michael Paquier wrote:
> > On Tue, Jul 07, 2020 at 09:58:59AM +0200, Daniel Gustafsson wrote:
> >> I agree, it looks like a copy-pasteo in 15cb2bd2700 which introduced the
> >> paragraph for both
On Tue, Jul 07, 2020 at 06:36:10PM +0900, Michael Paquier wrote:
> On Tue, Jul 07, 2020 at 09:58:59AM +0200, Daniel Gustafsson wrote:
>> I agree, it looks like a copy-pasteo in 15cb2bd2700 which introduced the
>> paragraph for both GIN and BRIN. LGTM. Adding Alexander who committed in on
>> cc.
>
On Tue, Jul 07, 2020 at 09:58:59AM +0200, Daniel Gustafsson wrote:
> I agree, it looks like a copy-pasteo in 15cb2bd2700 which introduced the
> paragraph for both GIN and BRIN. LGTM. Adding Alexander who committed in on
> cc.
+1.
--
Michael
signature.asc
Description: PGP signature
> On 7 Jul 2020, at 09:17, Guillaume Lelarge wrote:
> Here is a quick issue I found on the BRIN documentation. I'm not a 100% sure
> I'm right but it looks like a failed copy/paste from the GIN documentation.
I agree, it looks like a copy-pasteo in 15cb2bd2700 which introduced the
paragraph for
Hi,
Here is a quick issue I found on the BRIN documentation. I'm not a 100%
sure I'm right but it looks like a failed copy/paste from the GIN
documentation.
Cheers.
--
Guillaume.
diff --git a/doc/src/sgml/brin.sgml b/doc/src/sgml/brin.sgml
index 4c5eeb875f..55b6272db6 100644
--- a/doc/src/sgml
On Thu, Sep 19, 2019 at 2:15 PM Amit Kapila wrote:
>
> On Thu, Sep 19, 2019 at 1:40 PM Filip Rembiałkowski
> wrote:
> >
> > There is a small but eye catching glitch in the v12 (and master) docs
> > for "CREATE TABLE AS".
> >
> > https://www.postgresql.org/docs/12/sql-createtableas.html
> >
> > in
On Thu, Sep 19, 2019 at 1:40 PM Filip Rembiałkowski
wrote:
>
> There is a small but eye catching glitch in the v12 (and master) docs
> for "CREATE TABLE AS".
>
> https://www.postgresql.org/docs/12/sql-createtableas.html
>
> index b5c4ce6959..56d06838f1 100644
> --- a/doc/src/sgml/ref/create_table_
There is a small but eye catching glitch in the v12 (and master) docs
for "CREATE TABLE AS".
https://www.postgresql.org/docs/12/sql-createtableas.html
index b5c4ce6959..56d06838f1 100644
--- a/doc/src/sgml/ref/create_table_as.sgml
+++ b/doc/src/sgml/ref/create_table_as.sgml
@@ -146,7 +146,6 @@
"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
atch? I would bet that the code was also written
> on the assumption that any abbrevation must be unique.
There's a backward compatibility issue, since a script issuing
\pset format a
would now fail instead of setting the format to "aligned".
The doc patch is meant to describe
"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
but it turns out that it doesn't change the relative positions
of "aligned" / "asciidoc", or "latex" / "latex-longtables"
so \pset format a and \pset format l will continue to
select "aligned" and "latex" as before).
Anyway, &qu
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
Hello,
Please find below a submission of a patch to the PostgreSQL documentation.
You can also find the patch in this git commit:
https://gitlab.com/paulrbr/postgresql/commit/024d3870450df6dcdc69bddbe2de46084b73e3a2.diff
commit 024d3870450df6dcdc69bddbe2de46084b73e3a2
Author: Paul B
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
Hi,
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 added its explanation. Please read and revise it because I'm a non-nativ
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
Hi,
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.
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite
diff --git a/doc/src/sgm
83 matches
Mail list logo
