On 25.03.24 06:00, jian he wrote:
looking through v4 again.
v4 looks good to me.
Thanks, I have committed this.
looking through v4 again.
v4 looks good to me.
On 18.03.24 11:01, jian he wrote:
select relname from pg_class where relisshared and relkind = 'r';
relname
---
pg_authid
pg_subscription
pg_database
pg_db_role_setting
pg_tablespace
pg_auth_members
pg_shdepend
pg_shdescription
pg_replication_origin
On Mon, Mar 18, 2024 at 6:01 PM jian he wrote:
>
> On Mon, Mar 18, 2024 at 3:09 PM Peter Eisentraut wrote:
> >
> > On 14.03.24 01:26, Michael Paquier wrote:
> > > -EventTriggerSupportsObjectClass(ObjectClass objclass)
> > > +EventTriggerSupportsObject(const ObjectAddress *object)
> > >
> > > The
On Mon, Mar 18, 2024 at 3:09 PM Peter Eisentraut wrote:
>
> On 14.03.24 01:26, Michael Paquier wrote:
> > -EventTriggerSupportsObjectClass(ObjectClass objclass)
> > +EventTriggerSupportsObject(const ObjectAddress *object)
> >
> > The shortcut introduced here is interesting, but it is
On 14.03.24 01:26, Michael Paquier wrote:
-EventTriggerSupportsObjectClass(ObjectClass objclass)
+EventTriggerSupportsObject(const ObjectAddress *object)
The shortcut introduced here is interesting, but it is inconsistent.
HEAD treats OCLASS_SUBSCRIPTION as something supported by event
On Wed, Mar 13, 2024 at 02:24:32PM +0100, Peter Eisentraut wrote:
> On 08.03.24 06:50, Michael Paquier wrote:
>> This is usually taken care of by committers or updated automatically.
>
> both fixed
Looks mostly fine, thanks for the new version.
-EventTriggerSupportsObjectClass(ObjectClass
On 08.03.24 06:50, Michael Paquier wrote:
On Mon, Mar 04, 2024 at 09:29:03AM +0800, jian he wrote:
On Fri, Mar 1, 2024 at 5:26 PM Peter Eisentraut wrote:
Oops, there was a second commit in my branch that I neglected to send
in. Here is my complete patch set.
Thanks for the new patch set.
On Fri, 08 Mar 2024 at 13:21, Michael Paquier wrote:
> On Wed, Mar 06, 2024 at 08:24:09AM +0800, Japin Li wrote:
>> On Wed, 06 Mar 2024 at 01:53, Jelte Fennema-Nio wrote:
>>> I think if you remove the EEO_CASE(EEOP_LAST) block the warning should
>>> go away. That block is clearly marked as
On Mon, Mar 04, 2024 at 09:29:03AM +0800, jian he wrote:
> On Fri, Mar 1, 2024 at 5:26 PM Peter Eisentraut wrote:
>> Oops, there was a second commit in my branch that I neglected to send
>> in. Here is my complete patch set.
Thanks for the new patch set. The gains are neat, giving nice
On Wed, Mar 06, 2024 at 08:24:09AM +0800, Japin Li wrote:
> On Wed, 06 Mar 2024 at 01:53, Jelte Fennema-Nio wrote:
>> I think if you remove the EEO_CASE(EEOP_LAST) block the warning should
>> go away. That block is clearly marked as unreachable, so it doesn't
>> really serve a purpose.
>
>
On Wed, 06 Mar 2024 at 01:53, Jelte Fennema-Nio wrote:
> On Tue, 5 Mar 2024 at 15:30, Japin Li wrote:
>> There is a warning if remove it, so I keep it.
>>
>> /home/japin/Codes/postgres/build/../src/backend/executor/execExprInterp.c:118:33:
>> warning: label ‘CASE_EEOP_LAST’ defined but not
On Tue, 5 Mar 2024 at 15:30, Japin Li wrote:
> There is a warning if remove it, so I keep it.
>
> /home/japin/Codes/postgres/build/../src/backend/executor/execExprInterp.c:118:33:
> warning: label ‘CASE_EEOP_LAST’ defined but not used [-Wunused-label]
> 118 | #define EEO_CASE(name)
On Tue, 05 Mar 2024 at 22:03, Jelte Fennema-Nio wrote:
> On Tue, 5 Mar 2024 at 14:50, Japin Li wrote:
>> Attach a patch to rewrite dispatch_table array using C99-designated
>> initializer syntax.
>
> Looks good. Two small things:
Thanks for the review.
>
> + [EEOP_LAST] = &_EEOP_LAST,
>
On Tue, 5 Mar 2024 at 14:50, Japin Li wrote:
> Attach a patch to rewrite dispatch_table array using C99-designated
> initializer syntax.
Looks good. Two small things:
+ [EEOP_LAST] = &_EEOP_LAST,
Is EEOP_LAST actually needed in this array? It seems unused afaict. If
indeed not needed,
On Mon, 04 Mar 2024 at 07:46, Michael Paquier wrote:
> On Fri, Mar 01, 2024 at 06:30:10AM +0100, Jelte Fennema-Nio wrote:
>> On Fri, 1 Mar 2024 at 06:08, Michael Paquier wrote:
>>> Mostly OK to me. Just note that this comment is incorrect because
>>> pg_enc2gettext_tbl[] includes elements in
On Fri, Mar 1, 2024 at 5:26 PM Peter Eisentraut wrote:
>
> Oops, there was a second commit in my branch that I neglected to send
> in. Here is my complete patch set.
there is a `OCLASS` at the end of getObjectIdentityParts.
there is a `ObjectClass` in typedefs.list
On Fri, Mar 01, 2024 at 06:30:10AM +0100, Jelte Fennema-Nio wrote:
> On Fri, 1 Mar 2024 at 06:08, Michael Paquier wrote:
>> Mostly OK to me. Just note that this comment is incorrect because
>> pg_enc2gettext_tbl[] includes elements in the range
>> [PG_SJIS,_PG_LAST_ENCODING_[ ;)
>
> fixed
On 01.03.24 05:08, Michael Paquier wrote:
On Thu, Feb 29, 2024 at 12:41:38PM +0100, Peter Eisentraut wrote:
On 27.02.24 08:57, Alvaro Herrera wrote:
On 2024-Feb-27, Michael Paquier wrote:
These would cause compilation failures. Saying that, this is a very
nice cleanup, so I've fixed these
On Fri, Mar 1, 2024 at 12:08 PM Michael Paquier wrote:
>
> On Thu, Feb 29, 2024 at 12:41:38PM +0100, Peter Eisentraut wrote:
> > On 27.02.24 08:57, Alvaro Herrera wrote:
> >> On 2024-Feb-27, Michael Paquier wrote:
> >>> These would cause compilation failures. Saying that, this is a very
> >>>
On Fri, 1 Mar 2024 at 06:08, Michael Paquier wrote:
> Mostly OK to me. Just note that this comment is incorrect because
> pg_enc2gettext_tbl[] includes elements in the range
> [PG_SJIS,_PG_LAST_ENCODING_[ ;)
fixed
From 0d66d374697eff2b276b667ce24cf4599432dbd5 Mon Sep 17 00:00:00 2001
From:
On Fri, Mar 01, 2024 at 05:34:05AM +0100, Jelte Fennema-Nio wrote:
> diff --git a/src/include/mb/pg_wchar.h b/src/include/mb/pg_wchar.h
> index fd91aefbcb7..32e25a1a6ea 100644
> --- a/src/include/mb/pg_wchar.h
> +++ b/src/include/mb/pg_wchar.h
> @@ -225,7 +225,8 @@ typedef unsigned int pg_wchar;
On Fri, 1 Mar 2024 at 05:12, Michael Paquier wrote:
> Shouldn't PG_MULE_INTERNAL point to NULL in pg_enc2gettext_tbl[]?
> That just seems safer to me, and more consistent because its values
> satisfies PG_VALID_ENCODING().
Safety wise it doesn't matter, because gaps in a designated
initializer
On Thu, Feb 29, 2024 at 04:01:47AM +0100, Jelte Fennema-Nio wrote:
> On Thu, 29 Feb 2024 at 01:57, Michael Paquier wrote:
>> I have doubts about the changes in raw_pg_bind_textdomain_codeset(),
>> as the encoding could come from the value in the pg_database tuples
>> themselves. The current
On Thu, Feb 29, 2024 at 12:41:38PM +0100, Peter Eisentraut wrote:
> On 27.02.24 08:57, Alvaro Herrera wrote:
>> On 2024-Feb-27, Michael Paquier wrote:
>>> These would cause compilation failures. Saying that, this is a very
>>> nice cleanup, so I've fixed these and applied the patch after checking
On 27.02.24 08:57, Alvaro Herrera wrote:
On 2024-Feb-27, Michael Paquier wrote:
These would cause compilation failures. Saying that, this is a very
nice cleanup, so I've fixed these and applied the patch after checking
that the one-one replacements were correct.
Oh, I thought we were going
On Thu, 29 Feb 2024 at 01:57, Michael Paquier wrote:
> I have doubts about the changes in raw_pg_bind_textdomain_codeset(),
> as the encoding could come from the value in the pg_database tuples
> themselves. The current coding is slightly safer from the perspective
> of bogus input values as we
On Wed, Feb 28, 2024 at 05:37:22AM +0100, Jelte Fennema-Nio wrote:
> On Wed, 28 Feb 2024 at 04:59, Michael Paquier wrote:
>> Cool. I have applied 0004 and most of 0002. Attached is what
>> remains, where I am wondering if it would be cleaner to do these bits
>> together (did not look at the
On Wed, 28 Feb 2024 at 04:59, Michael Paquier wrote:
> Cool. I have applied 0004 and most of 0002. Attached is what
> remains, where I am wondering if it would be cleaner to do these bits
> together (did not look at the whole, yet).
Feel free to squash them if you prefer that. I think now that
On Wed, Feb 28, 2024 at 09:41:42AM +0800, Japin Li wrote:
> On Wed, 28 Feb 2024 at 00:06, Jelte Fennema-Nio wrote:
>> Attached is v5 of the patchset that also includes this change (with
>> you listed as author).
>
> Thanks for updating the patch!
Cool. I have applied 0004 and most of 0002.
On Wed, 28 Feb 2024 at 00:06, Jelte Fennema-Nio wrote:
> On Tue, 27 Feb 2024 at 16:04, Japin Li wrote:
>> I see the config_group_names[] needs null-terminated because of help_config,
>> however, I didn't find the reference in help_config.c. Is this comment
>> outdated?
>
> Yeah, you're
On Tue, 27 Feb 2024 at 16:04, Japin Li wrote:
> I see the config_group_names[] needs null-terminated because of help_config,
> however, I didn't find the reference in help_config.c. Is this comment
> outdated?
Yeah, you're correct. That comment has been outdated for more than 20
years. The
On Tue, 27 Feb 2024 at 19:55, Jelte Fennema-Nio wrote:
> On Tue, 27 Feb 2024 at 12:52, Jelte Fennema-Nio wrote:
>> Attached is an updated patchset to also convert pg_enc2icu_tbl and
>> pg_enc2gettext_tbl. I converted pg_enc2gettext_tbl in a separate
>> commit, because it actually requires some
On Tue, 27 Feb 2024 at 08:57, Alvaro Herrera wrote:
> What this says to me is that ObjectClass is/was a somewhat useful
> abstraction layer on top of catalog definitions. I'm now not 100% that
> poking this hole in the abstraction (by expanding use of catalog OIDs at
> the expense of
On Tue, 27 Feb 2024 at 12:52, Jelte Fennema-Nio wrote:
> Attached is an updated patchset to also convert pg_enc2icu_tbl and
> pg_enc2gettext_tbl. I converted pg_enc2gettext_tbl in a separate
> commit, because it actually requires some codechanges too.
Another small update to also make all arrays
On Tue, 27 Feb 2024 at 07:25, Michael Paquier wrote:
> About 0002, I can't help but notice pg_enc2icu_tbl and
> pg_enc2gettext_tb. There are exceptions like MULE_INTERNAL, but is it
> possible to do better?
Attached is an updated patchset to also convert pg_enc2icu_tbl and
pg_enc2gettext_tbl. I
On Tue, 27 Feb 2024 at 07:25, Michael Paquier wrote:
>
> On Mon, Feb 26, 2024 at 05:00:13PM +0800, Japin Li wrote:
> > On Mon, 26 Feb 2024 at 16:41, jian he wrote:
> >> obvious typo errors.
>
> These would cause compilation failures. Saying that, this is a very
> nice cleanup, so I've fixed
On 2024-Feb-27, Michael Paquier wrote:
> These would cause compilation failures. Saying that, this is a very
> nice cleanup, so I've fixed these and applied the patch after checking
> that the one-one replacements were correct.
Oh, I thought we were going to get rid of ObjectClass altogether --
On Mon, Feb 26, 2024 at 05:00:13PM +0800, Japin Li wrote:
> On Mon, 26 Feb 2024 at 16:41, jian he wrote:
>> obvious typo errors.
These would cause compilation failures. Saying that, this is a very
nice cleanup, so I've fixed these and applied the patch after checking
that the one-one
On Mon, Feb 26, 2024 at 05:00:13PM +0800, Japin Li wrote:
> On Mon, 26 Feb 2024 at 16:41, jian he wrote:
>> similarly, last entry, no need an extra comma?
>> also other places last array entry no need extra comma.
>
> For last entry comma, see [1].
>
> [1]
>
On Mon, 26 Feb 2024 at 16:41, jian he wrote:
> Hi. minor issues.
>
> @@ -2063,12 +2009,12 @@ find_expr_references_walker(Node *node,
> CoerceViaIO *iocoerce = (CoerceViaIO *) node;
>
> /* since there is no exposed function, need to depend on type */
> - add_object_address(OCLASS_TYPE,
Hi. minor issues.
@@ -2063,12 +2009,12 @@ find_expr_references_walker(Node *node,
CoerceViaIO *iocoerce = (CoerceViaIO *) node;
/* since there is no exposed function, need to depend on type */
- add_object_address(OCLASS_TYPE, iocoerce->resulttype, 0,
+ add_object_address(TypeRelationId
On Fri, 23 Feb 2024 at 02:57, Jeff Davis wrote:
> Sorry, I was unclear. I was asking a question about the reason the
> ObjectClass and the object_classes[] array exist in the current code,
> it wasn't a direct question about your patch.
I did a bit of git spelunking and the reason seems to be
On Fri, 2024-02-23 at 01:35 +0100, Jelte Fennema-Nio wrote:
> On Thu, Feb 22, 2024, 23:46 Jeff Davis wrote:
> >
> > Am I missing something?
>
> The main benefits it has are:
Sorry, I was unclear. I was asking a question about the reason the
ObjectClass and the object_classes[] array exist in
On Thu, Feb 22, 2024, 23:46 Jeff Davis wrote:
>
> Am I missing something?
The main benefits it has are:
1. The order of the array doesn't have to exactly match the order of the
enum for the arrays to contain the correct mapping.
2. Typos in the enum variant names are caught by the compiler
On Wed, 2024-02-21 at 16:03 +0100, Jelte Fennema-Nio wrote:
> Usage of designated initializers came up in:
> https://www.postgresql.org/message-id/flat/ZdWXhAt9Tz4d-lut%40paquier.xyz#9dc17e604e58569ad35643672bf74acc
>
> This converts all arrays that I could find that could clearly benefit
> from
Usage of designated initializers came up in:
https://www.postgresql.org/message-id/flat/ZdWXhAt9Tz4d-lut%40paquier.xyz#9dc17e604e58569ad35643672bf74acc
This converts all arrays that I could find that could clearly benefit
from this without any other code changes being necessary.
There were a few
47 matches
Mail list logo
