s.
>
> Best regards,
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese:http://www.sraoss.co.jp
--
Yugo Nagata
" (IMMs) would be good. So, how about using this for now?
When other better opinions are raised, let's discuss again
Regards,
Yugo Nagata
>
> Best regards,
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese:http://www.sraoss.co.jp
--
Yugo Nagata
The following review on our patch was posted on another thread,
so I quote here. The tab completion is Hoshiai-san's work, so
he will handle this issue.
Regards,
Yugo Nagata.
On Thu, 28 Nov 2019 13:00:05 +0900
nuko yokohama wrote:
> Hi.
>
> I'm using the "Incre
Hello nuko-san,
Thank you for your review!
As Michael commentted, we would like to discuss this on the thread
of the patch, so I quote your review in the following post.
https://www.postgresql.org/message-id/20191129154513.943f4ef05896d7b9d3fed69f%40sraoss.co.jp
Regards,
Yugo Nagata
On Thu
e could use combine functions to calculate new
aggregate values in IVM when tuples are inserted into a table. However, in
the context of IVM, we also need other function used when tuples are deleted
from a table, so we can not use partial aggregation for IVM in the current
implementation. This might be
ng it isolated seems
> like a good way to attract more eyeballs.
>
> * Someone well versed in trigger infrastructure can help fine tune the
> patch for (2)
>
> and so on.
>
> So, please consider giving some thought to this.
Agreed. Although I am not sure we will do it as above way, we will
consider to split the patch, anyway. Thanks.
Regards,
Yugo Nagata
--
Yugo Nagata
On Fri, 29 Nov 2019 18:16:00 +0900
Yugo Nagata wrote:
> On Fri, 29 Nov 2019 15:34:52 +0900
> Amit Langote wrote:
>
> > Thanks a lot for working on this. It's a great (and big!) feature and
> > I can see that a lot of work has been put into writing this patch. I
able
> > to handle correctly. Supported aggregates can be identified using their
> > OIDs.
> > User-defined aggregates are not supported. I think this is the simplest and
> > easiest way.
>
> I think this is enough for the first cut of IVM. So +1.
If there is no objection, I will add the check of aggregate functions
by this way. Thanks.
Regards,
Yugo Nagata
--
Yugo Nagata
On Mon, 2 Dec 2019 13:48:40 -0300
Alvaro Herrera wrote:
> On 2019-Dec-02, Yugo Nagata wrote:
>
> > On Mon, 02 Dec 2019 10:36:36 +0900 (JST)
> > Tatsuo Ishii wrote:
> >
> > > >> One thing pending in this development line is how to catalogue
> >
table will fail.
>
> Error message.
> ```
> ERROR: could not open relation with OID 0
Thank you for your pointing out this issue! This error occurs
because the view's OID is retrieved using the view name.
Considering that the name can be changed, this is obviously
wrong. We'l
would be easy for inner joins
or aggregate views, but there is some difficult with outer joins.
Regards,
Yugo Nagata
--
Yugo Nagata
IVM_patches_v10.tar.gz
Description: application/gzip
w returns incorrect results.
> To prevent this, we propose that the same error occur when a non-IMMUTABLE
> expression is specified in the "CREATE INDEX" statement.
Thank you for pointing out this. That makes sense. The check of not-IMMUTABLE
epressions is missing at creating IMMV
ou concern occurs. So, it seems worth to consider the way to
reduce use of temptable.
Regards,
Yugo Nagata
--
Yugo Nagata
On Mon, 23 Dec 2019 08:08:53 +
"tsunakawa.ta...@fujitsu.com" wrote:
> From: Yugo Nagata
> > 1. Create a temporary table only once at the first view maintenance in
> > this session. This is possible if we store names or oid of temporary
> > tables used for e
rg/message-id/flat/157703426606.1198.2452090605041230054.pgcf%40coridan.postgresql.org#331e8344bbae904350af161fb43a0aa6
Although I have not looked into this thread, this may be help if this is
implemented. However, it would be still necessary to truncate the table
before the view maintenance because such tables always exist and can be
accessed and modified by any users.
--
Yugo Nagata
On Tue, 24 Dec 2019 07:07:35 +
"tsunakawa.ta...@fujitsu.com" wrote:
> From: Yugo Nagata
> > On Mon, 23 Dec 2019 08:08:53 +
> > "tsunakawa.ta...@fujitsu.com" wrote:
> > > How about unlogged tables ? I thought the point of using a te
On Mon, 15 Jan 2024 16:49:44 +0900 (JST)
Tatsuo Ishii wrote:
> > On Wed, 6 Sep 2023 20:13:34 +0900
> > Yugo NAGATA wrote:
> >
> >> I attached the updated patch v3. The changes since the previous
> >> patch includes the following;
> >>
> >&g
40mail.gmail.com
Regards,
Yugo Nagata
> ==
> [1] https://commitfest.postgresql.org/46/4337/
> [2] https://cirrus-ci.com/task/6607979311529984
>
> Kind Regards,
> Peter Smith.
--
Yugo NAGATA
* required because all threads running queries continue to run without
+* interrupted even when the signal is received.
+ *
Attached is the updated patch, v6.
> Best reagards,
> --
> Tatsuo Ishii
> SRA OSS LLC
> English: http://www.sraoss.co.jp/index_en/
> Japanese:http://www.
Size
> Functions).
I could not find any change in your patch from my previous patch.
Maybe, you attached wrong file. I attached a patch updated based
on your review, including the documentation fixes and a test.
What do you think about this it?
Regards,
Yugo Nagata
--
Yugo NAGATA
>From
introduced in a4fd3aa719e, where this function
was moved from psql.
Regards,
Yugo Nagata
--
Yugo NAGATA
diff --git a/src/bin/pg_dump/parallel.c b/src/bin/pg_dump/parallel.c
index 188186829c..261b23cb3f 100644
--- a/src/bin/pg_dump/parallel.c
+++ b/src/bin/pg_dump/parallel.c
@@ -204,7 +204,7
iption more accurate.
Regards,
Yugo Nagata
--
Yugo NAGATA
diff --git a/doc/src/sgml/ref/copy.sgml b/doc/src/sgml/ref/copy.sgml
index 21a5c4a052..14c8ceab06 100644
--- a/doc/src/sgml/ref/copy.sgml
+++ b/doc/src/sgml/ref/copy.sgml
@@ -577,8 +577,8 @@ COPY count
COPY stops operation at
On Fri, 26 Jan 2024 13:59:09 +0900
Masahiko Sawada wrote:
> On Fri, Jan 26, 2024 at 11:28 AM Yugo NAGATA wrote:
> >
> > Hi,
> >
> > I found that the documentation of COPY ON_ERROR said
> > COPY stops operation at the first error when
> > "ON_ERR
On Fri, 26 Jan 2024 15:26:55 +0900
Masahiko Sawada wrote:
> On Fri, Jan 26, 2024 at 2:40 PM Yugo NAGATA wrote:
> >
> > On Fri, 26 Jan 2024 13:59:09 +0900
> > Masahiko Sawada wrote:
> >
> > > On Fri, Jan 26, 2024 at 11:28 AM Yugo NAGATA wrote:
> > &g
On Thu, 25 Jan 2024 23:33:22 -0700
"David G. Johnston" wrote:
> On Thu, Jan 25, 2024 at 10:40 PM Yugo NAGATA wrote:
>
> > On Fri, 26 Jan 2024 13:59:09 +0900
> > Masahiko Sawada wrote:
> >
> > > On Fri, Jan 26, 2024 at 11:28 AM Yugo NAGATA
>
On Fri, 26 Jan 2024 00:00:57 -0700
"David G. Johnston" wrote:
> On Thursday, January 25, 2024, Yugo NAGATA wrote:
>
> >
> > Maybe, we can separate the sentese to two, for example:
> >
> > COPY stops operation at the first error. (The exception i
On Fri, 26 Jan 2024 08:04:45 -0700
"David G. Johnston" wrote:
> On Fri, Jan 26, 2024 at 2:30 AM Yugo NAGATA wrote:
>
> > On Fri, 26 Jan 2024 00:00:57 -0700
> > "David G. Johnston" wrote:
> >
> > > I will need to make this tweak and proba
rstand “as if you deleted it” as their operational concept more
> readily than visible. I think this will be read by people who haven’t read
> MVCC to fully understand what visible means but know enough to run vacuum
> to clean up updated and deleted data as a rule.
Ok, I agree we can omit "or accessible". How do you like the followings?
Still redundant?
"If the command fails, these rows are left in a deleted state;
these rows will not be visible, but they still occupy disk space. "
Regards,
Yugo Nagata
--
Yugo NAGATA
soft error, although the syntax would be a bit complex...)
IMO, it is more simple to define "ignore" as to skip the entire row rather
than having variety of "ignore". Once defined it so, the option to set the
column value to NULL should not be called "ignore" because values in other
columns will be inserted.
Regards,
Yugo Nagata
>
> David J.
--
Yugo NAGATA
On Tue, 30 Jan 2024 12:12:31 +0800
jian he wrote:
> On Fri, Jan 26, 2024 at 8:42 AM Yugo NAGATA wrote:
> >
> > On Tue, 2 Jan 2024 08:00:00 +0800
> > jian he wrote:
> >
> > > On Mon, Nov 6, 2023 at 8:00 AM jian he
> > > wrote:
> > > >
On Tue, 30 Jan 2024 13:47:45 +0800
jian he wrote:
> On Tue, Jan 30, 2024 at 12:35 PM Yugo NAGATA wrote:
> >
> >
> > Sorry, I also attached a wrong file.
> > Attached is the correct one.
> I think you attached the wrong file again. also please name it as v4.
Opps
On Tue, 30 Jan 2024 13:44:28 +0100
Daniel Gustafsson wrote:
> > On 26 Jan 2024, at 01:42, Yugo NAGATA wrote:
>
> > I am proposing it because there is a public function with
> > the same name in fe_utils/cancel.c. I know pg_dump/parallel.c
> > does not include fe_uti
On Tue, 30 Jan 2024 14:57:20 +0800
jian he wrote:
> On Tue, Jan 30, 2024 at 1:56 PM Yugo NAGATA wrote:
> >
> > I attached the correct one, v4.
> >
>
> +-- Test pg_column_toast_chunk_id:
> +-- Check if the returned chunk_id exists in the TOAST table
> +CREATE
On Mon, 29 Jan 2024 15:47:25 +0900
Yugo NAGATA wrote:
> On Sun, 28 Jan 2024 19:14:58 -0700
> "David G. Johnston" wrote:
>
> > > Also, I think "invalid input syntax" is a bit ambiguous. For example,
> > > COPY FROM raises an error when the num
On Fri, 02 Feb 2024 11:29:41 +0900
torikoshia wrote:
> On 2024-02-01 15:16, Yugo NAGATA wrote:
> > On Mon, 29 Jan 2024 15:47:25 +0900
> > Yugo NAGATA wrote:
> >
> >> On Sun, 28 Jan 2024 19:14:58 -0700
> >> "David G. Johnston" wrote:
> >&g
t;
> I've attached a patch to fix it in case this is a typo.
I also think it should be ">="
Also, if so, I don't think the check of MINIMUM_VERSION_FOR_PG_WAL
in the block is required, because the directory name is always pg_wal
in the new versions.
Regards,
Yugo Nagata
>
> --
> Artur
--
Yugo NAGATA
I can't see any existing defences.
>
> One simple way to address that would be to make XLogFileInitInternal()
> wait for InstallXLogFileSegment() to finish. It's a little
Or, can we make sure the rename is durable by calling fsync before
returning the fd, as a patch attached her
On Sat, 3 Feb 2024 01:51:56 +0200
Alexander Korotkov wrote:
> On Fri, Feb 2, 2024 at 10:07 PM David G. Johnston
> wrote:
> > On Thu, Feb 1, 2024 at 11:59 PM Yugo NAGATA wrote:
> >>
> >>
> >> I attached a updated patch including fixes you pointed out above
On Thu, 1 Feb 2024 17:59:56 +0800
jian he wrote:
> On Thu, Feb 1, 2024 at 12:45 PM Yugo NAGATA wrote:
> >
> > Here is a updated patch, v6.
>
> v6 patch looks good.
Thank you for your review and updating the status to RwC!
Regards,
Yugo Nagata
--
Yugo NAGATA
so I suggested to use
"set_to_null" or more generic syntax like "set_to (col, val)" in my
previous post[1], although I'm not convinced what is the best either.
[1]
https://www.postgresql.org/message-id/20240129172858.ccb6c77c3be95a295e2b2b44%40sraoss.co.jp
Regards,
Yugo Nagata
--
Yugo NAGATA
On Tue, 06 Feb 2024 09:39:09 +0900 (JST)
Kyotaro Horiguchi wrote:
> At Mon, 5 Feb 2024 17:22:56 +0900, Yugo NAGATA wrote in
> > On Mon, 05 Feb 2024 11:28:59 +0900
> > torikoshia wrote:
> >
> > > > Based on this, I've made a patch.
> > > &
s too strong because it is very
common that a table has a primary key, unless there is some way
to specify columns that can be set to NULL. Even when ON_ERROR
is specified, any constraint violation errors cannot be generally
ignored, so we cannot elimiate the posibility COPY FROM fails in
the middle due to invalid data, anyway.
Regards,
Yugo Nagata
--
Yugo NAGATA
On Wed, 24 Jan 2024 22:17:44 +0900
Yugo NAGATA wrote:
> Attached is the updated patch, v6.
Currently, on non-Windows, SIGINT is received only by thread #0.
CancelRequested is checked during the loop in the thread, and
queries are cancelled if it is set. However, once thread #0 exits
the l
On Wed, 7 Feb 2024 22:59:48 +0100
Daniel Gustafsson wrote:
> > On 1 Feb 2024, at 02:21, Yugo NAGATA wrote:
> > On Tue, 30 Jan 2024 13:44:28 +0100
> > Daniel Gustafsson wrote:
>
> >> -setup_cancel_handler(void)
> >> +pg_dump_setup_cancel_handler(v
function.
Regards,
Yugo Nagata
--
Yugo NAGATA
diff --git a/src/backend/nodes/queryjumblefuncs.c b/src/backend/nodes/queryjumblefuncs.c
index e489bfceb5..e4fbcf0d9f 100644
--- a/src/backend/nodes/queryjumblefuncs.c
+++ b/src/backend/nodes/queryjumblefuncs.c
@@ -42,8 +42,8 @@
/* GUC parameters */
int
On Sat, 10 Feb 2024 10:19:15 +0900
Michael Paquier wrote:
> On Fri, Feb 09, 2024 at 04:37:23PM +0800, Julien Rouhaud wrote:
> > On Fri, Feb 09, 2024 at 03:38:23PM +0900, Yugo NAGATA wrote:
> >> Also, I think the name is a bit confusing for the same reason, that is,
> >&
; separate function and call it.
Ok. I made a new function "discardUntilSync" for the pipeline cleaning.
> I think that the report should not remove data when they are 0, otherwise it
> makes
> it harder to script around it (in failures_detailed on line 6284).
I fixed to report bo
d. In other places
> "link" tag is used instead:
Thank you for pointing out it.
I've checked other places using referring to , and found
that "xreflabel"s are used in such tags. So, I'll fix it
in this style.
Regards,
Yugo Nagata
--
Yugo NAGATA
uot; as well as "cycles". However, I am not sure
that the situation is improved by using such word because what such word
exactly means seems to be still unclear for users.
Another idea is instead reporting only "the number of successfully
retried transactions" that does not include "failed transactions",
that is, transactions failed after retries, like this;
number of transactions actually processed: 100/100
number of failed transactions: 0 (0.000%)
number of successfully retried transactions: 35 (35.000%)
total number of retries: 74
The meaning is clear and there seems to be no confusion.
Regards,
Yugo Nagata
--
Yugo NAGATA
On Tue, 22 Mar 2022 09:08:15 +0900
Yugo NAGATA wrote:
> Hi Ishii-san,
>
> On Sun, 20 Mar 2022 09:52:06 +0900 (JST)
> Tatsuo Ishii wrote:
>
> > Hi Yugo,
> >
> > I have looked into the patch and I noticed that > linkend=... endterm=...> is used in pgbe
ed the
> new entry there, and I have added a test checking after an error for
> multiple subcommands, while on it.
>
> Thanks, Nagata-san!
Thank you!
--
Yugo NAGATA
ges.
I have edited the test code from the original patch by mistake, but
I could not realize because the test works in my machine without any
errors somehow.
I attached a patch to fix the test as was in the original patch, where
backreferences are used to check retry of the same query.
Regards,
Yugo
On Fri, 25 Mar 2022 09:14:00 +0900 (JST)
Tatsuo Ishii wrote:
> > Note that the \\g2 just above also needs to be changed.
>
> Oops. Thanks. New patch attached. Test has passed on my machine.
This patch works for me. I think it is ok to use \N instead of \gN.
Regards,
Yugo Naga
ded items will be
> precisou information. I would suggest leave the log items as it is.
>
> Patch attached.
Even applying this patch, "make postgres-A4.pdf" arises the warning on my
machine. After some investigations, I found that previous document had a break
after 'num_tr
behavior.
Currently, pgbench fails to execute the above script in prepared mode
because it prepares the entire script in advance just before the first
command execution. This patch does not change the semantic.
> BTW, the cfbot says the patch is failing to apply anyway ...
> I think it was sideswi
s', but it has been removed due to this commit.
>
> Yes, your patch removed "&zwsp;".
>
> > So,
> > I would like to get back this as it was. I attached the patch.
>
> This produces errors. Needs ";" postfix?
Oops. Yes, it needs ';'. A
On Wed, 25 Nov 2020 18:00:16 +0300
Konstantin Knizhnik wrote:
>
>
> On 25.11.2020 16:06, Yugo NAGATA wrote:
> > On Wed, 25 Nov 2020 15:16:05 +0300
> > Konstantin Knizhnik wrote:
> >
> >>
> >> On 24.11.2020 13:11, Yugo NAGATA wrote:
> >>
or false, users can use the old format for calling this
and the backward compatibility can be maintained.
As another comment, while pg_is_wal_replay_paused is blocking, I can not cancel
the query. I think CHECK_FOR_INTERRUPTS() is necessary in the waiting loop.
+ errhint("Recovery control functions can only be executed
during recovery.")));
There are a few tabs at the end of this line.
Regards,
Yugo Nagata
--
Yugo NAGATA
e that the effect
of the optimization.
Regards,
Yugo Nagata
--
Yugo NAGATA
IVM_patches_v20.tar.gz
Description: application/gzip
so, we plan to support only
selection, projection, inner-join, and some aggregates in the first
release and leave sub-queries, outer-join, and CTE supports to the
next release.
Regards,
Yugo Nagata
On Tue, 22 Dec 2020 21:51:36 +0900
Yugo NAGATA wrote:
> Hi,
>
> Attached is the revi
On Wed, 14 Feb 2024 07:21:54 +0900
Michael Paquier wrote:
> On Tue, Feb 13, 2024 at 11:23:47PM +0800, Julien Rouhaud wrote:
> > +1!
>
> Okay, applied as-is, then.
Thank you!
Regards,
Yugo Nagata
> --
> Michael
--
Yugo NAGATA
tion
query, so I wonder the Assert condition would be a bit complex. Could
you explain what are you assume about like for example?
Regards,
Yugo Nagata
--
Yugo NAGATA
utes the query and the result rows to
"dest_new". And, replace_rte_with_delta updates the input argument "rte"
and returns the result to it, so it may be better that this returns void,
as you suggested.
Regards,
Yugo Nagata
--
Yugo NAGATA
remove code around sigsetjmp in
do_watch(). I've attached the patch for this fix.
Regards,
Yugo Ngata
--
Yugo NAGATA
diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c
index 5c906e4806..c03e47744e 100644
--- a/src/bin/psql/command.c
+++ b/src/bin/psql/command.c
@@ -5312,20 +53
On Wed, 06 Mar 2024 13:03:39 -0500
Tom Lane wrote:
> Michael Paquier writes:
> > On Tue, Mar 05, 2024 at 10:05:52PM +0900, Yugo NAGATA wrote:
> >> In the current code of do_watch(), sigsetjmp is called if WIN32
> >> is defined, but siglongjmp is not called in the
ct the
cancel at this timing because currently we use PQsendQuery which is asynchronous
and does not wait the result. We have to check cancel_pressed after PQgetResult
call. I'm also attached a patch for this, with some comments fix.
Regards,
Yugo Nagata
--
Yugo NAGATA
diff --git a/src/b
On Thu, 7 Mar 2024 16:56:17 -0600
Nathan Bossart wrote:
> On Mon, Feb 05, 2024 at 04:28:23PM +0900, Yugo NAGATA wrote:
> > On Thu, 1 Feb 2024 17:59:56 +0800
> > jian he wrote:
> >> v6 patch looks good.
> >
> > Thank you for your review and updating the
On Fri, 8 Mar 2024 16:17:58 -0600
Nathan Bossart wrote:
> On Fri, Mar 08, 2024 at 03:31:55PM +0900, Yugo NAGATA wrote:
> > On Thu, 7 Mar 2024 16:56:17 -0600
> > Nathan Bossart wrote:
> >> to me. Do you think it's worth adding something like a
> >> pg_c
On Fri, 08 Mar 2024 12:09:12 -0500
Tom Lane wrote:
> Yugo NAGATA writes:
> > On Wed, 06 Mar 2024 13:03:39 -0500
> > Tom Lane wrote:
> >> I don't have Windows here to test on, but does the WIN32 code
> >> path work at all?
>
> > The outer loop
On Sat, 9 Mar 2024 08:50:28 -0600
Nathan Bossart wrote:
> On Sat, Mar 09, 2024 at 11:57:18AM +0900, Yugo NAGATA wrote:
> > On Fri, 8 Mar 2024 16:17:58 -0600
> > Nathan Bossart wrote:
> >> Is this guaranteed to be TOASTed for all possible page sizes?
> >
On Tue, 12 Mar 2024 22:07:17 -0500
Nathan Bossart wrote:
> I did some light editing to prepare this for commit.
Thank you. I confirmed the test you improved and I am fine with that.
Regards,
Yugo Nagata
>
> --
> Nathan Bossart
> Amazon Web Services: https://aws.amazon.com
--
Yugo NAGATA
On Thu, 14 Mar 2024 11:10:42 -0500
Nathan Bossart wrote:
> On Wed, Mar 13, 2024 at 01:09:18PM +0700, Yugo NAGATA wrote:
> > On Tue, 12 Mar 2024 22:07:17 -0500
> > Nathan Bossart wrote:
> >> I did some light editing to prepare this for commit.
> >
> >
te scripts and the list of updates specified in updates_without_script.
Presence of update script has higher priority than the option. Therefore,
if an update script is provided, the script will be executed even if this
update is specified in updates_without_script.
What do you think of this featu
Hi,
Thank you for your comment.
On Mon, 30 Jan 2023 16:05:52 -0500
Tom Lane wrote:
> Yugo NAGATA writes:
> > Currently, even when we don't need to execute any command to update an
> > extension from one version to the next, we need to provide an update
> > scrip
_attr(equal_ignore);
In this case, pg_node_attr is mistakenly interpreted to be
the name of the field. So, I propose to use -I option of ctags
to ignore the marco name. Attached is a patch to do it.
Regards,
Yugo Nagata
--
Yugo NAGATA
diff --git a/src/tools/make_ctags b/src/tools/make_ctags
Hello
On Mon, 10 Oct 2022 12:04:22 +0200
Alvaro Herrera wrote:
> Hello
>
> On 2022-Oct-07, Yugo NAGATA wrote:
>
> > I found that tag files generated by src/tools/make_ctags
> > doesn't include some keywords, that were field names of node
> > structs, for
gt; the links.
>
> Also I have changed make_etags so that it exec make_ctags, which seems
> to be the consensus.
Thank you for following up my patch.
I fixed the patch to allow use both -e and -n options together.
Regards,
Yugo Nagata
>
> Best reagards,
> --
> Tatsuo Is
Hello Micheal-san,
On Thu, 13 Oct 2022 17:02:06 +0900
Michael Paquier wrote:
> On Fri, Sep 30, 2022 at 10:12:13AM +0900, Yugo NAGATA wrote:
> > Thank you for comment. Do you think it can be marked as Ready for Commiter?
>
> Matviews have been discarded from needing predic
;s no objection.
I am fine with this patch.
By the way, in passing, how about adding "tags" and "TAGS" to
.gitignore file?
>
> Best reagards,
> --
> Tatsuo Ishii
> SRA OSS LLC
> English: http://www.sraoss.co.jp/index_en/
> Japanese:http://www.sraoss.co.jp
--
Yugo NAGATA
; > I fixed the patch to allow use both -e and -n options together.
> >>
> >> Thanks. I have made mostly cosmetic changes so that it is more
> >> consistent with existing scripts.
> >>
> >> I would like to push v6 patch if there's no objection.
> &
files?
> Best reagards,
> --
> Tatsuo Ishii
> SRA OSS LLC
> English: http://www.sraoss.co.jp/index_en/
> Japanese:http://www.sraoss.co.jp
--
Yugo NAGATA
tags -e) and it was
just for testing the patch. Similarly, someone who runs mistakenly this
command might want this option. However, as you say, there've been no
complain about this, so I don't feel it necessary so much. Maybe, users
of this command would be able to remove tags by their selves easily.
Regards,
Yugo Nagata
--
Yugo NAGATA
On Sun, 06 Nov 2022 12:54:17 -0500
Tom Lane wrote:
> Yugo NAGATA writes:
> >> The attached patch tries to add comments explaining it on the functions.
>
> > I forward it to the hackers list because the patch is to fix comments.
>
> What do you think of the attached
On Wed, 09 Nov 2022 11:17:29 -0500
Tom Lane wrote:
> Yugo NAGATA writes:
> > Tom Lane wrote:
> >> What do you think of the attached wording?
>
> > It looks good to me. That describes the expected behaviour exactly.
>
> Pushed that, then.
Thank you.
> &g
solution,
although I have once withdrawn this for not breaking backward compatibility.
Attached is the same patch of [1].
[1]
https://www.postgresql.org/message-id/20220728105134.d5ce51dd756b3149e9b9c52c%40sraoss.co.jp
Regards,
Yugo Nagata
--
Yugo NAGATA
On Thu, 10 Nov 2022 15:33:37 -0500
Tom Lane wrote:
> Yugo NAGATA writes:
> > Tom Lane wrote:
> >> Hmm. Maybe the right way to think about this is "if we have completed an
> >> EXECUTE, and not yet received a following SYNC, then report that we are in
> &g
$2) AND (b <= $3))
-> Seq Scan on ab_a2_b3 ab_3 (actual rows=0 loops=1)
Filter: ((a >= $1) AND (a <= $2) AND (b <= $3))
(8 rows)
Regards,
Yugo Nagata
--
Yugo NAGATA
On Wed, 1 Feb 2023 14:37:27 +0800
Julien Rouhaud wrote:
> Hi,
>
> On Tue, Jan 31, 2023 at 11:17:22AM +0900, Yugo NAGATA wrote:
> >
> > On Mon, 30 Jan 2023 16:05:52 -0500
> > Tom Lane wrote:
> >
> > > If you have no update script, why call it a
On Wed, 1 Feb 2023 16:52:07 +1300
David Rowley wrote:
> On Wed, 1 Feb 2023 at 15:53, Yugo NAGATA wrote:
> > Maybe, you missed to set plan_cache_mode to force_generic_plan.
> > "Subplan Removed" doesn't appear when using a custom plan.
>
> I wouldn't
ract" both JSON blobs so that the 'newrow' only
> contains the members that differ? I would like to have this:
>
> ─[ RECORD 1
> ]
> op │ U
> datetime │ 2023-02-01 01:16:44.704036+01
> oldrow │ {"year": 2021, "brand": "Sunrise", "winery": "Concha y Toro",
> "bottles": 12, "variety": "Chardonnay"}
> newrow │ {"bottles": 108}
> ─[ RECORD 2
> ]
> op │ U
> datetime │ 2023-02-01 01:16:44.704036+01
> oldrow │ {"year": 2022, "brand": "Sunrise", "winery": "Concha y Toro",
> "bottles": 12, "variety": "Merlot"}
> newrow │ {"bottles": 132}
>
> --
> Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/
> "La gente vulgar sólo piensa en pasar el tiempo;
> el que tiene talento, en aprovecharlo"
>
>
--
Yugo NAGATA
.
However, I think we would want a comment on the added line. Also, the
attached test should be placed in the regression test.
Regards,
Yugo Nagata
>
> [1] https://commitfest.postgresql.org/41/3641/
>
> --
> Antonin Houska
> Web: https://www.cybertec-postgresql.com
>
--
Yugo NAGATA
On Wed, 01 Feb 2023 11:47:23 -0500
Tom Lane wrote:
> Yugo NAGATA writes:
> > Antonin Houska wrote:
> >> While working on [1] I noticed that if RLS gets enabled, the COPY TO
> >> command
> >> includes the contents of child table into the result, although t
the commit make_etags on Mac failed anyway. Do we want make_etags to
> restore the previous behavior? i.e. 'etags' program not found
>
> >> If so, we should revert the changes of make_etags by the commit and
> >> make make_etags work with that ctags?
>
&
;--help" might be intended rather than "--version" to check
supported options? Even so, ctags would have other option whose name contains
"-e" than Emacs support, so this check could end in a wrong result. Therefore,
it seems to me that it is better to check immediately if e
pport for access to regular tables is ".
Ragards,
Yugo Nagata
--
Yugo NAGATA
diff --git a/doc/src/sgml/xindex.sgml b/doc/src/sgml/xindex.sgml
index c753d8005a..ff73233818 100644
--- a/doc/src/sgml/xindex.sgml
+++ b/doc/src/sgml/xindex.sgml
@@ -30,11 +30,8 @@
The pg_am table co
, I chose "some" to mean "unknown or unspecified", not "an unspecified
amount
or number of", so singular form "error" is used.
Instead, should we use "due to a error"?
> Also:
> + --exit-on-abort is specified . Otherwise in the
>
; > or number of", so singular form "error" is used.
>
> Ok.
>
> > Instead, should we use "due to a error"?
>
> I don't think so.
>
> >> Also:
> >> + --exit-on-abort is specified . Otherwise in the
> >> wor
On Thu, 29 Jun 2023 00:40:45 +0800
jian he wrote:
> On Wed, Jun 28, 2023 at 4:06 PM Yugo NAGATA wrote:
> >
> > On Wed, 28 Jun 2023 00:01:02 +0800
> > jian he wrote:
> >
> > > On Thu, Jun 1, 2023 at 2:47 AM Yugo NAGATA wrote:
> > > >
> &
On Thu, 29 Jun 2023 18:20:32 +0800
jian he wrote:
> On Thu, Jun 29, 2023 at 12:40 AM jian he wrote:
> >
> > On Wed, Jun 28, 2023 at 4:06 PM Yugo NAGATA wrote:
> > >
> > > On Wed, 28 Jun 2023 00:01:02 +0800
> > > jian he wrote:
> > >
> &
m']
> error: file doc/src/sgml/postgres-full.xml
> xsltRunStylesheet : run failed
> ninja: build stopped: subcommand failed.
Thank your for pointing out this.
I'll add ids for all sections to suppress the errors.
Regards,
Yugo Nagata
--
Yugo NAGATA
201 - 300 of 597 matches
Mail list logo
