j), so there
> might be some possibilities.
When a character that cannot be displayed in PDF is found, a warning
"Glyph ... not available in font " is output in fop's log. We can
prevent such characters from being contained in PDF by checking
the message as the attached
r patch includes fixes in *.svg files, so how about checking
also them by check-non-ascii? Also, I think it is better to use perl instead
of grep because non-GNU grep doesn't support hex escape sequences. I've attached
a updated patch for Makefile. The changes in release.sgml above i
On Fri, 11 Oct 2024 21:00:47 +1300
David Rowley wrote:
> On Fri, 11 Oct 2024 at 20:53, Yugo Nagata wrote:
> > It is not applied to the web (yet?), though.
> > https://www.postgresql.org/docs/17/release-17.html
>
> Those will only be updated when 17.1 is released.
Thank yo
On Thu, 26 Sep 2024 14:21:27 +0900
Yugo NAGATA wrote:
> On Thu, 26 Sep 2024 13:27:54 +0930
> Tom Dunstan wrote:
>
> > On Thu, 26 Sept 2024 at 13:21, Yugo Nagata wrote:
> >
> > > By the way, this is not mentioned in CREATE MATERIALIZED VIEW
> > > docum
; Okay for me as long as the patch is pushed to master branch.
> >>>
> >>> A small comment on the comments in the patch: pgindent dislikes some
> >>> of the comment indentation styles. See attached pgindent.txt. Although
> >>> such a small defect would be fixed by committers when a patch gets
> >>> committed anyway, you might want to help committers beforehand.
> >>
> >> Thank you for your comments.
> >> I've attached a updated patch that I applied pgindent.
> >
> > The patch looks good to me. If there's no objection, I will commit and
> > push the patch to master branch. I don't think this should be
> > back-patched since it modifies the user visible behavior of pgbench.
>
> Patch pushed.
Thanks!
Regards,
Yugo Nagata
--
Yugo NAGATA
t, so this is a dead code to be removed.
> >
> > The Assert for RELKIND_MATVIEW in heapam_hander.c was introduced in
> > d25f519107b
> > after that, but I think it can be also removed.
> >
>
> Thank you for your feedback and support!
>
> I also add this as a post in Commit Fest [0]
>
>
> [0] https://commitfest.postgresql.org/50/5292/
I marked it as Ready-for-Committer.
Regards,
Yugo Nagata
--
Yugo NAGATA
s like
"as COPY".
To prevent users to face unexpected experiences, how about explaining
explicitly that
file_fdw uses COPY and updates pg_stat_progress_copy?
> To prevent misleading reports when multiple commands are run concurrently,
> just idea, we could consider displaying NULL columns in the progress report
> if this situation is detected, as a separate patch.
Or, could we add additional field to pg_stat_progress_copy to
show how much commands are running COPY? It is also just idea.
Regards,
Yugo Nagata
--
Yugo Nagata
uot;stylesheet-man.xsl" also has non-ascii
> > characters. I don't know these characters are really necessary though, since
> > I don't understand this file well.
>
> They are U+201C (double turned comma quotation mark) and U+201D
> (double comma quotation mark).
>
>
>
> I would like to know why they are necessary too.
+1
Regards,
Yugo Nagata
--
Yugo NAGATA
3ab8c563 and at that UNLOGGED was
allowed, and it is disallowed by another commit 3223b25ff73. However,
it seems that the tab-complement is missed to fixed.
The Assert for RELKIND_MATVIEW in heapam_hander.c was introduced in d25f519107b
after that, but I think it can be also removed.
Regards,
Yugo N
when lines in it are modified.
I've attached a patch to add a simple Perl script to do this.
During testing this script, I found "stylesheet-man.xsl" also has non-ascii
characters. I don't know these characters are really necessary though, since
example, when
applying WAL
record is delayed due to conflict with recovery or recovery_min_apply_delay.
It might be better if if could notice that there is not requested record in the
primary's
timeline before requesting the streaming, but I don't have a good solution for
now.
Regards,
Yugo Nagata
On Tue, 8 Oct 2024 21:37:38 -0700
"David G. Johnston" wrote:
> On Tuesday, October 8, 2024, Tom Lane wrote:
>
> > "David G. Johnston" writes:
> > > On Tuesday, October 8, 2024, Yugo Nagata wrote:
> > >> On Wed, 09 Oct 2024 11:10:37 +090
the details in the script.
>
> Do you think?
I am not sure if it is good to include psql's meta-command in pg_dump/pg_dumpall
results. Can we assume users will always use psql to restore the pg_dump
results?
Regards,
Yugo Nagata
--
Yugo Nagata
equivalent meson target).
>
> Can we check for any character outside the support range of SGML?
What we can define the range of allowed characters range in SGML?
We can detect non-ASCII characters by using regexp /\P{ascii}/ or
/[^\x00-\x7f]/,
but they are used in some
here a link to that commit, too?
> >
> > I developed the attached patch which adds the two commands and the
> > commit item.
>
> Okay, updated commit after running src/tools/add_commit_links.pl.
LGTM. Thank you.
Regards,
Yugo Nagata
--
Yugo NAGATA
On Tue, 1 Oct 2024 22:20:55 +0900
Yugo Nagata wrote:
> On Tue, 1 Oct 2024 15:16:52 +0900
> Yugo NAGATA wrote:
>
> > On Tue, 01 Oct 2024 10:33:50 +0900 (JST)
> > Tatsuo Ishii wrote:
> >
> > > >> That's because non-breaking space (nbsp) is not e
tion". However, after all, I'm fine with either any way.
If we use "the failover parameter", I would read "enable the failover parameter"
as "enable the failover parameter on executing ALTER SUBSCRIPTION command".
Otherwise in the "failover option" case,
on, you must manually create the replication slot,
> enable the failover if required, enable the subscription, and refresh the
> subscription.
Instead, should we use "failover option"? Or, if it would mean to the failover
feature rather than the parameter, is it not proper to add tag to this
"failover"?
Regards,
Yugo Nagata
--
Yugo Nagata
; storage parameters in CREATE TABLE doc might be also
> > targets to be
> > rewritten. I am not sure if this covers all, though.
>
> I would like to hear opinions from native English speakers.
+1
Regards,
Yugo Nagata
--
Yugo NAGATA
>
>
> The following parameters control what happens during subscription
> creation:
>
> So it seems "paramter" is more consistent than "option" here.
For consistency, using "parameter" seems better.
If we consider this, should we r
g to "failover" since it is done in the
description on "slot_name" parameter.
How about also rewrite it to "enable the failover option" rather than simply
"enable the failover" to clarify that the parameter is refereed to.
We could also use "enab
On Tue, 1 Oct 2024 15:16:52 +0900
Yugo NAGATA wrote:
> On Tue, 01 Oct 2024 10:33:50 +0900 (JST)
> Tatsuo Ishii wrote:
>
> > >> That's because non-breaking space (nbsp) is not encoded as 0xa0 in
> > >> UTF-8. nbsp in UTF-8 is "0xc2 0xa0" (2
scape according
to [1].
[1]
https://stackoverflow.com/questions/24275070/sed-not-giving-me-correct-substitute-operation-for-newline-with-mac-difference
By the way, I've attached a patch a bit modified to use the plural form
statement
as same as check-tabs.
Non-breaking **spaces** appear
P option can be used in only GNU grep, and grep in mac
doesn't support it.
On bash, we can also use `grep $'\xc2\xa0'`, but I am not sure we can assume
the shell is bash.
Maybe, better way is use perl itself rather than grep as following.
`perl -ne '/\xC2\xA0/ and print' `
ED VIEW, REINDEX, and LOCK TABLE on all relations."
Regards,
Yugo Nagata
--
Yugo Nagata
ot;[\xA0]"` instead of `grep -e "\xA0"`.
However, it also detects the following line in charset.sgml.
(https://www.postgresql.org/docs/current/collation.html)
For example, locale und-u-kb sorts 'àe' before 'aé'.
This is not non-breaking space, so should not be detected as an error.
Regards,
Yugo Nagata
> --
> Daniel Gustafsson
>
--
Yugo Nagata
eaking spaces, as well as
one found in line 85 of ref/drop_extension.sgml.
Regards,
Yugo Nagata
>
> Best reagards,
> --
> Tatsuo Ishii
> SRA OSS K.K.
> English: http://www.sraoss.co.jp/index_en/
> Japanese:http://www.sraoss.co.jp
--
Yugo NAGATA
; Tatsuo Ishii
> SRA OSS K.K.
> English: http://www.sraoss.co.jp/index_en/
> Japanese:http://www.sraoss.co.jp
--
Yugo NAGATA
ch does not apply
I found your patch contains an odd character (ASCII Code 240?)
by performing `od -c` command on the file. See the attached file.
Regards,
Yugo Nagata
>
> Best reagards,
> --
> Tatsuo Ishii
> SRA OSS K.K.
> English: http://www.sraoss.co.jp/index_en/
>
On Wed, 21 Aug 2024 09:11:03 +0800
px shi wrote:
> Yugo Nagata 于2024年8月21日周三 00:49写道：
>
> >
> >
> > > Is s1 a cascading standby of s2? If otherwise s1 and s2 is the standbys
> > of
> > > the primary server respectively, it is not surprising that s2 has
On Sat, 28 Sep 2024 21:19:11 -0400
Bruce Momjian wrote:
> On Thu, Sep 26, 2024 at 02:19:21PM +0900, Yugo Nagata wrote:
> > On Thu, 9 May 2024 00:03:50 -0400
> > Bruce Momjian wrote:
> >
> > > I have committed the first draft of the PG 17 release notes; you
hink patch authors looking for OIDs they can use will run unused_oids,
so more likely notice this.
Regards,
Yugo Nagata
--
Yugo Nagata
On Thu, 26 Sep 2024 16:33:06 -0500
Nathan Bossart wrote:
> On Mon, Aug 05, 2024 at 04:05:02PM +0900, Yugo Nagata wrote:
> > +
> > + While CREATE MATERIALIZED VIEW is running, the > + linkend="guc-search-path"/> is temporarily changed to
> > pg_cat
On Thu, 26 Sep 2024 17:16:07 +0900
Michael Paquier wrote:
> On Fri, Sep 13, 2024 at 03:56:11PM +0900, Yugo Nagata wrote:
> > I confirmed the patches are committed in the master branch.
> > Thank you!
> >
> > I've updated the commitfest status to "committed
On Thu, 26 Sep 2024 13:27:54 +0930
Tom Dunstan wrote:
> On Thu, 26 Sept 2024 at 13:21, Yugo Nagata wrote:
>
> > By the way, this is not mentioned in CREATE MATERIALIZED VIEW
> > documentation, although
> > we can find in REFRESH MATERIALIZED VIEW doc. So, I sent
e-14: 220
> release-15: 184
> release-16: 206
> release-17: 188
>
> I welcome feedback. For some reason it was an easier job than usual.
>
> --
> Bruce Momjian https://momjian.us
> EDB https://enter
not mentioned in CREATE MATERIALIZED VIEW documentation,
although
we can find in REFRESH MATERIALIZED VIEW doc. So, I sent the doc patch in [1],
and create a commitfest entry [2].
[1]
https://www.postgresql.org/message-id/20240805160502.d2a4975802a832b1e04afb80%40sraoss.co.jp
[2] https://commitfest.pos
te line.
>
> Okay for me as long as the patch is pushed to master branch.
>
> A small comment on the comments in the patch: pgindent dislikes some
> of the comment indentation styles. See attached pgindent.txt. Although
> such a small defect would be fixed by committers when
tency stddev = 466.328 ms
- statement latencies in milliseconds and failures:
0.426 0 begin;
5352.229 0 lock b;
2003.416 0 select pg_sleep(2);
0.829 3 lock a;
8.774 0 end;
I've attached the update
of faild transactions. Also, I added a check of script_total_cnt before
reporting per-script number of failed transactions.
Regards,
Yugo Nagata
--
Yugo Nagata
>From 000340660f2c567164d7f33cf622f8225a046262 Mon Sep 17 00:00:00 2001
From: Yugo Nagata
Date: Thu, 19 Sep 2024 01:37:54 +0900
On Fri, 26 Apr 2024 17:54:06 +0900
Yugo NAGATA wrote:
> On Wed, 24 Apr 2024 16:08:39 -0500
> Nathan Bossart wrote:
>
> > On Tue, Apr 23, 2024 at 11:47:38PM -0400, Tom Lane wrote:
> > > On the whole I find this proposed feature pretty unexciting
> > > and dubio
On Thu, 12 Sep 2024 19:51:33 +0900
Yugo NAGATA wrote:
> On Thu, 12 Sep 2024 19:07:22 +0900
> Fujii Masao wrote:
>
> >
> >
> > On 2024/09/10 17:45, Yugo NAGATA wrote:
> > > On Mon, 9 Sep 2024 22:59:34 +0900
> > > Fujii Masao wrote:
> > >
On Thu, 12 Sep 2024 19:07:22 +0900
Fujii Masao wrote:
>
>
> On 2024/09/10 17:45, Yugo NAGATA wrote:
> > On Mon, 9 Sep 2024 22:59:34 +0900
> > Fujii Masao wrote:
> >
> >>
> >>
> >> On 2024/07/02 16:34, Yugo NAGATA wrote:
> >>>
On Mon, 9 Sep 2024 22:59:34 +0900
Fujii Masao wrote:
>
>
> On 2024/07/02 16:34, Yugo NAGATA wrote:
> > So, I would like to propose to add
> > has_large_object_function for checking if a user has the privilege on a
> > large
> > object.
>
> +1
Tha
On Mon, 9 Sep 2024 12:16:01 +0900
Michael Paquier wrote:
> On Fri, Sep 06, 2024 at 08:10:43PM +0900, Yugo Nagata wrote:
> > Since 1bb2558046c, XLogFileRead() doesn't use the emode argument.
> > Also, since abf5c5c9a4f, XLogFileReadAnyTLI() is called just once
> > and
,
the function returns without using newExpectedTLEs, nor releasing it. I wonder
this is a memory leak and it is better to release it, although the affect may
be not so much.
I've attached the patch.
Regards,
Yugo Nagata
--
Yugo Nagata
diff --git a/src/backend/access/transam/xlogrecover
Hi,
Since 1bb2558046c, XLogFileRead() doesn't use the emode argument.
Also, since abf5c5c9a4f, XLogFileReadAnyTLI() is called just once
and emode is always DEBUG2. So, I think we can remove the emode
argument from these functions. I've atached the patch.
Regards,
Yugo Nagata
--
Y
On Thu, 22 Aug 2024 09:10:52 +0200
Peter Eisentraut wrote:
> On 22.08.24 08:15, Yugo Nagata wrote:
> > On Thu, 22 Aug 2024 11:38:49 +0800
> > jian he wrote:
> >
> >> On Wed, Aug 21, 2024 at 4:57 PM Peter Eisentraut
> >> wrote:
> >>>
> &g
rrhint is wrong?
Yes. I think we don't have to output the hint message if we disallow USING
for generated columns. Or, it may be useful to allow only a simple cast
for the generated column instead of completely prohibiting USING.
Regards,
Yugo Nagata
--
Yugo Nagata
is patch adds a check to error out if this is specified.
I’m afraid you forgot to attach the patch.
It seems for me that this fix is reasonable though.
Regards,
Yugo Nagata
>
> There was a test for this, but that test errored out for a different
> reason, so it was not effective.
>
&g
ry server respectively, it is not surprising that s2 has progressed
far than s1 when the primary fails. I believe that this is the case you should
use pg_rewind. Even if flushedUpto is reset as proposed in your patch, s2 might
already have applied a WAL record that s1 has not processed yet, and there
would be no gurantee that subsecuent applys suceed.
Regards,
Yugo Nagata
--
Yugo Nagata
xist, error out */
> if (stat(XLOGDIR, &stat_buf) != 0 ||
> !S_ISDIR(stat_buf.st_mode))
Should be the follwing also rewritten using sizeof(PG_REPLSLOT_DIR)?
struct stat statbuf;
charpath[MAXPGPATH * 2 + 12];
Regards,
Yugo Nagata
--
Yugo Nagata
er ad d the same comment in dropdb(). I attached a trivial
patch for it.
Regards,
Yugo Nagata
--
Yugo Nagata
diff --git a/src/backend/commands/dbcommands.c b/src/backend/commands/dbcommands.c
index 7a7e2c6e3e..d00ae40e19 100644
--- a/src/backend/commands/dbcommands.c
+++ b/src/backend/com
ce should start with "This ... ".
> >
> > + while(size)
> > + {
> >
> > I wonder inserting a space after "while" is the standard style.
>
> Thanks, fixed.
Should we fix the comment on byteaGetByte in passing, too?
Regards,
Yugo Nagata
--
Yugo Nagata
as the newvalue argument
useful? I wonder it would eliminate the restrict that size cannot be larger
than 8.
Here are my very trivial comments on the patch.
+ * this routine treats "bytea" as an array of bytes.
Maybe, the sentence should start with "This ... ".
+ while
!= NULL)
{
charpath[MAXPGPATH + 12];
PGFileType de_type;
I think the size of path can be rewritten to "MAXPGPATH +
sizeof(PG_REPLSLOT_DIR)"
and it seems easier to understand the reason why this size is used.
(That said, I wonder the path would never longer than MAXPGPATH...)
Regards,
Yugo Nagata
>
> Regards,
>
> --
> Bertrand Drouvot
> PostgreSQL Contributors Team
> RDS Open Source Databases
> Amazon Web Services: https://aws.amazon.com
--
Yugo Nagata
On Tue, 06 Aug 2024 11:24:03 -0700
Jeff Davis wrote:
> On Wed, 2024-08-07 at 03:06 +0900, Yugo Nagata wrote:
> > I'm sorry. After sending the mail, I found the patch didn't work.
> > If we call RestrictSearchPath() before creating a relation, it tries
> > to create
On Wed, 7 Aug 2024 02:13:04 +0900
Yugo Nagata wrote:
> On Thu, 01 Aug 2024 13:34:51 -0700
> Jeff Davis wrote:
>
> > On Fri, 2024-08-02 at 00:13 +0500, Kirill Reshke wrote:
> > > On Thu, 1 Aug 2024 at 23:27, Jeff Davis wrote:
> > > >
> > > > EXP
ersions, so we've lived with it for a while, and
> I don't see a security problem here. I wouldn't expect it to be a
> common use case, either.
I agree that we don't have to rush it since it is not a security bug
but just it could make a materialized view that cannot be ref
ld make EXPLAIN support REFRESH MATERIALIZED VIEW CONCURRENTLY
command, how should we handle these additional queries?
Regards,
Yugo Nagata
--
Yugo Nagata
On Fri, 2 Aug 2024 16:13:01 +0900
Yugo NAGATA wrote:
> On Thu, 01 Aug 2024 11:31:53 -0700
> Jeff Davis wrote:
>
> > On Wed, 2024-07-31 at 18:20 +0900, Yugo NAGATA wrote:
> > > I agree that it might not be important, but I think adding the flag
> > > would be
On Thu, 01 Aug 2024 11:31:53 -0700
Jeff Davis wrote:
> On Wed, 2024-07-31 at 18:20 +0900, Yugo NAGATA wrote:
> > I agree that it might not be important, but I think adding the flag
> > would be
> > also helpful for improving code-readability because it clarify the
> >
Hi,
On Fri, 26 Jul 2024 16:47:23 -0700
Jeff Davis wrote:
> Hello,
>
> Thank you for looking.
>
> On Fri, 2024-07-26 at 12:26 +0900, Yugo Nagata wrote:
> > Since this commit, matviews are no longer handled in
> > ExecCreateTableAs, so the
> > following
Hi,
On Tue, 30 Jul 2024 01:36:55 +0200
Erik Wienhold wrote:
> On 2024-07-01 15:08 +0200, Yugo NAGATA wrote:
> > I would like to propose to add a new field to psql's \dAo+ meta-command
> > to show whether the underlying function of an operator is leak-proof.
>
> +1 f
ted.
Thank you so much for a lot of comments!
I will respond to the comments soon.
> >
> > On Thu, 11 Jul 2024 at 09:24, Yugo NAGATA wrote:
> > >
> > > I updated the patch to bump up the version numbers in psql and pg_dump
> > > codes
> > >
L
as queryEnv arg in CreateQueryDesc to avoid to create useless matviews
accidentally,
as the attached patch?
Regards,
Yugo Nagata
--
Yugo Nagata
diff --git a/src/backend/commands/createas.c b/src/backend/commands/createas.c
index e91920ca14..fda1e4d92b 100644
--- a/src/backend/commands/createas
t
the previous
LSN segment number when the LSN was on a file segment boundary; it now
returns the LSN segment.
It might be trivial, but, reading the associated commit message , I think it
would be more explicit
for users to rewrite the last statement to
"it now returns the current LSN se
freshMatView since this is public
for a
long time, but I don't think the new interface RefreshMatViewByOid has to have
this
unused argument.
I attaehd patches for fixing them respectedly.
What do you think about it?
Regards,
Yugo Nagata
--
Yugo Nagata
>From 854d01bfbdece781bad46ab68
On Thu, 4 Jul 2024 11:06:03 +0200
Jelte Fennema-Nio wrote:
> On Thu, 4 Jul 2024 at 06:46, Yugo NAGATA wrote:
> > Attached is a small patch to fix a comment on PQcancelErrorMessage.
>
> Oops, copy paste mistake on my part I guess. New comment LGTM
Thank you for your comments.
I
Hi,
Attached is a small patch to fix a comment on PQcancelErrorMessage.
It was accidentally "Get the socket of the cancel connection."
I rewrote it to "Returns the error message most recently generated
by an operation on the cancel connection."
Regards,
Yugo Nagata
--
Yug
ct id is
specified, and false if non-existing user id is specified, and raises an error
if
non-existing user name is specified. These behavior is similar with
has_table_privilege.
The regression test is also included.
Regards,
Yugo Nagata
--
Yugo NAGATA
On Sun, 23 Jun 2024 19:14:09 +0900
Yugo NAGATA wrote:
> and Operator Families"? Additionally, is it useful to add LEAKPROOF
> information
> to the result of psql \dAo(+) meta-comand, or a function that can check given
> index
> or operator is leakproof or not?
I worte a p
The attached patch adds the field to \dAo+ and also a description that
explains the relation between indexes and security quals with referencing
\dAo+ meta-command.
[1]
https://www.postgresql.org/message-id/raw/5af3bf0c-5e0c-4128-81dc-084c5258b1af%40code406.com
Regards,
Yugo Nagata
--
Yugo N
ongpathexample2ple1
In the current uses, BackupState is freed (by pfree or MemoryContextDelete)
after each use of BackupState, so the memory space is not reused as your
scenario above, and there would not harms even if the null-termination is
omitted.
However, I wonder it is better to use strlcpy without assuming such the good
manner of callers.
Regards,
Yugo Nagata
>
> It's not a good idea to use memcpy with strlen.
>
> best regards,
> Ranier Vilela
--
Yugo NAGATA
On Mon, 24 Jun 2024 08:37:26 -0300
Ranier Vilela wrote:
> Em seg., 24 de jun. de 2024 às 00:27, Yugo NAGATA
> escreveu:
>
> > On Sun, 23 Jun 2024 22:34:03 -0300
> > Ranier Vilela wrote:
> >
> > > Em dom., 23 de jun. de 2024 às 22:14, Ranier Vilela >
On Tue, 18 Jun 2024 23:02:14 -0700
"David G. Johnston" wrote:
> On Tuesday, June 18, 2024, Tom Lane wrote:
>
> > Yugo NAGATA writes:
> > > On Tue, 18 Jun 2024 20:56:58 -0700
> > > "David G. Johnston" wrote:
> > >> But it is n
change the size of the field,
but if change it, I wonder it is better to modify the following
message from MAXPGPATH to MAXPGPATH -1.
errmsg("backup label too long (max %d bytes)",
MAXPGPATH)));
Regards,
Yugo Nagata
>
> So, I think that v3 is ok to fix.
>
> best regards,
> Ranier Vilela
>
> >
> > best regards,
> > Ranier Vilela
> >
> >>
--
Yugo NAGATA
ation familiar, for example, "11.10. Operator
Classes
and Operator Families"? Additionally, is it useful to add LEAKPROOF information
to the result of psql \dAo(+) meta-comand, or a function that can check given
index
or operator is leakproof or not?
Regards,
Yugo Nagata
> Thanks
#x27;s good for amcostestimate() to modify the
>
> IndexPath directly as the PoC patch does.
I am not sure it is the best way to modify IndexPath in amcostestimate(), but
I don't have better ideas for now.
Regards,
Yugo Nagata
>
>
>
>
> Regards,
>
> --
>
> Masahiro Ikeda
>
> NTT DATA CORPORATION
>
>
--
Yugo NAGATA
On Tue, 18 Jun 2024 20:56:58 -0700
"David G. Johnston" wrote:
> On Tue, Jun 18, 2024 at 8:34 PM Yugo NAGATA wrote:
>
> >
> > It may be a trivial thing but I am not sure we need to mention case
> > insensitivity
> > here, because all keywords and unqu
vial thing but I am not sure we need to mention case
insensitivity
here, because all keywords and unquoted identifiers are case-insensitive in
PostgreSQL and it is not specific to NULL.
Also, I found the other parts of the documentation use "case-insensitive" in
which
words are joined with hyphen, so I wonder it is better to use the same form if
we
leave the description.
Regards,
Yugo Nagata
--
Yugo NAGATA
On Fri, 26 Apr 2024 12:23:45 +0200
Matthias van de Meent wrote:
> On Fri, 26 Apr 2024 at 10:54, Yugo NAGATA wrote:
> >
> > On Wed, 24 Apr 2024 16:08:39 -0500
> > Nathan Bossart wrote:
> >
> > > On Tue, Apr 23, 2024 at 11:47:38PM -0400, Tom Lane wrote:
>
re offset information or some way
to convert a offset to chunk_seq.
Regards,
Yugo Nagata
> --
> Nathan Bossart
> Amazon Web Services: https://aws.amazon.com
--
Yugo NAGATA
On Thu, 25 Apr 2024 10:26:41 +0200
Peter Eisentraut wrote:
> On 24.04.24 15:25, Tom Lane wrote:
> > Peter Eisentraut writes:
> >> On 24.04.24 11:59, Yugo NAGATA wrote:
> >>> I noticed that a permission check is performed in be_lo_put()
> >>> just afte
>Pfdebug, message, &logCursor);
> break;
+1
I prefer the new function names since it seems more natural and easier to read.
I noticed pqTraceOutputNR() is left as is, is this intentional? Or, shoud this
be changed to pqTranceOutput_NoticeResponse()?
Regards,
Yugo Nagata
>
Hi,
I noticed that a permission check is performed in be_lo_put()
just after returning inv_open(), but teh permission should be
already checked in inv_open(), so I think we can remove this
part of codes. I attached a patch for this fix.
Regards,
Yugo Nagata
--
Yugo NAGATA
diff --git a/src
"missing {support function | operator} %d(%u,%u) in opfamily %u"
in several places.
Regards,
Yugo Nagata
>
> maybe
> if (!OidIsValid(equality_op)) /* shouldn't happen */
> elog(ERROR, "missing operator =(%u,%u) in opfamily %u",opcintype,
> opcint
PRIVILEGES ] }
ON TABLES
TO { [ GROUP ] role_name | PUBLIC } [, ...] [ WITH GRANT OPTION ]
I attached a small patch to fix the description.
Regards,
Yugo Nagata
--
Yugo NAGATA
diff --git a/doc/src/sgml/ref/alter_default_privileges.sgml b/doc/src/sgml/ref/alter_default_privileges.
On Tue, 23 Apr 2024 23:47:38 -0400
Tom Lane wrote:
> Yugo NAGATA writes:
> > Currently, ALTER DEFAULT PRIVILEGE doesn't support large objects,
> > so if we want to allow users other than the owner to use the large
> > object, we need to grant a privilege on it every
ed to be specified
for large objects since any large objects don't belong to a schema.
The attached patch is originally proposed by Haruka Takatsuka
and some fixes and tests are made by me.
Regards,
Yugo Nagata
--
Yugo NAGATA
>From fe2cb39bd83d09a052d5d63889acd0968c1817b6 Mon Sep 17
oblem I found in [1].
[1]
https://www.postgresql.org/message-id/20240207101903.b5846c25808f64a91ee2e7a2%40sraoss.co.jp
Regards,
Yugo Nagata
> --
> Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/
> "La fuerza no está en los medios físicos
> s
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.
> >
> >
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 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 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 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 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
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 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
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
1 - 100 of 538 matches
Mail list logo
