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 inconsistent.
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
triggers,
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 objcla
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. T
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 unre
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
numbers:
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.
>
> Thanks
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 used
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) CAS
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] = &&CASE_EEOP_LAS
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] = &&CASE_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 th
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
(For
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 and
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
> >>> nic
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: Jelt
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 ar
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 codin
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 t
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 w
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 whol
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. Att
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 correct
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 commi
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 ObjectClass)
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 thes
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 replacement
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]
> https://www.postgresql.org/message-i
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, iocoer
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 iocoe
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 tha
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 th
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 beca
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 be
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
On Tue, Oct 4, 2022 at 5:48 PM Michael Paquier wrote:
>
> On Tue, Oct 04, 2022 at 04:20:36PM +1100, Peter Smith wrote:
> > The v2 patches are updated as follows:
> >
> > 0001 - Now this patch only fixes a comment that had a wrong enum name.
>
> This was wrong, so fixed.
Thanks for pushing!
>
> >
On Tue, Oct 04, 2022 at 04:20:36PM +1100, Peter Smith wrote:
> The v2 patches are updated as follows:
>
> 0001 - Now this patch only fixes a comment that had a wrong enum name.
This was wrong, so fixed.
> 0002 - Removes unnecessary whitespace (same as v1-0002)
This one does not seem worth doing
me order as those
> > > enums. There are comments to say what enum index belongs to each table
> > > element.
> > > But why not use designated initializers to enforce what the comments
> > > are hoping for?
> >
> > Interesting proposal, but it's n
o each table
> > element.
> > But why not use designated initializers to enforce what the comments
> > are hoping for?
>
> Interesting proposal, but it's not clear to me that this solution makes
> the code more bulletproof rather than less so. Yeah, you removed th
Peter Smith writes:
> Enums index a number of the GUC tables. This all relies on the
> elements being carefully arranged to be in the same order as those
> enums. There are comments to say what enum index belongs to each table
> element.
> But why not use designated initializers
On Tue, Sep 27, 2022 at 09:27:48AM +1000, Peter Smith wrote:
> But why not use designated initializers to enforce what the comments
> are hoping for?
This is a C99 thing as far as I understand, adding one safety net.
Why not for these cases..
> Doing this also exposed a minor ty
Hi hackers,
Enums index a number of the GUC tables. This all relies on the
elements being carefully arranged to be in the same order as those
enums. There are comments to say what enum index belongs to each table
element.
But why not use designated initializers to enforce what the comments
are
Hello
On 2022-Aug-10, Andres Freund wrote:
> +1 I've fought with this one when fixing a conflict when rebasing a patch...
Right -- pushed, thanks.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
Hi,
On 2022-08-10 16:03:00 +0200, Alvaro Herrera wrote:
> (Coming from
> https://postgr.es/m/20220809193616.5uucf33piwdxn452@alvherre.pgsql )
>
> On 2022-Aug-09, Alvaro Herrera wrote:
>
> > On 2022-Aug-09, Andres Freund wrote:
> >
> > > Mildly wonderin
(Coming from https://postgr.es/m/20220809193616.5uucf33piwdxn452@alvherre.pgsql
)
On 2022-Aug-09, Alvaro Herrera wrote:
> On 2022-Aug-09, Andres Freund wrote:
>
> > Mildly wondering whether we ought to use designated initializers instead,
> > given we're whacking it arou
On 30/08/2018 22:14, Andres Freund wrote:
> I think we should have as rules:
>
> 1) Members should be defined in the same order as in the struct, that's
>the requirement C++ standard is going to impose. Think it's also
>reasonable stylistically.
> 2) It's OK to omit setting members if zero
Mark Dilger writes:
> I tried doing this perhaps a year ago, and there are a few files with arrays
> of structs whose representations get much larger when you change the format
> in this way. For instance, in guc.c:
> ...
> What should the general rule be for initializing arrays of structs such a
#x27;s very opaque and I have to refer
> to the struct definition each time I want to add a new member, to make
> sure I'm assigning the right thing.
Dito. Especially because it looks different for the different types of
GUCs.
> I welcome designated initializers in this case even
On Wed, Aug 29, 2018 at 6:51 PM, Tom Lane wrote:
> I agree that assuming that they're physically zeroes is OK from a
> portability standpoint, because we'd have a whole lot of other issues
> if they weren't. But I have a different point to make, which is that
> it's fairly standard practice for u
can
> plans."),
> NULL
> },
> &enable_seqscan,
> true,
> NULL, NULL, NULL
> },
Personally, I dislike this form -- it's very opaque and I have to refer
to the struct definition each time I want to add a new member, to make
sure I'm assigning t
> On Aug 29, 2018, at 1:51 PM, David Steele wrote:
>
> On 8/29/18 5:14 AM, Peter Eisentraut wrote:
>> On 29/08/2018 12:13, Peter Eisentraut wrote:
>>> Here is a patch to change some struct initializations to use C99-style
>>> designated initializers.
Hi,
On 2018-08-29 18:51:24 -0400, Tom Lane wrote:
> I agree that assuming that they're physically zeroes is OK from a
> portability standpoint, because we'd have a whole lot of other issues
> if they weren't. But I have a different point to make, which is that
> it's fairly standard practice for
Hi,
On 2018-08-29 20:35:57 -0400, Chapman Flack wrote:
> On 08/29/18 18:51, Tom Lane wrote:
>
> > As against that, of course, explicitly zeroing fields that you know very
> > well are already zero eats some cycles. I've occasionally wondered if
>
> I haven't checked what a smart C99 compiler ac
On 08/29/18 18:51, Tom Lane wrote:
> As against that, of course, explicitly zeroing fields that you know very
> well are already zero eats some cycles. I've occasionally wondered if
I haven't checked what a smart C99 compiler actually emits for a
designated initializer giving a field a compile-t
Andres Freund writes:
> On 2018-08-29 15:51:07 -0500, David Steele wrote:
>> One thing: I'm not sure that excluding the InvalidOid assignment in the
>> TopTransactionStateData initializer is a good idea. That is, it's not clear
>> that InvalidOid is 0.
>> NULL, false, and 0 seem like no-brainers,
On Thu, Aug 30, 2018 at 8:51 AM David Steele wrote:
> On 8/29/18 5:14 AM, Peter Eisentraut wrote:
> > On 29/08/2018 12:13, Peter Eisentraut wrote:
> >> Here is a patch to change some struct initializations to use C99-style
> >> designated initializers. These are just a
Hi,
On 2018-08-29 15:51:07 -0500, David Steele wrote:
> One thing: I'm not sure that excluding the InvalidOid assignment in the
> TopTransactionStateData initializer is a good idea. That is, it's not clear
> that InvalidOid is 0.
>
> NULL, false, and 0 seem like no-brainers, but maybe it would b
On 8/29/18 5:14 AM, Peter Eisentraut wrote:
On 29/08/2018 12:13, Peter Eisentraut wrote:
Here is a patch to change some struct initializations to use C99-style
designated initializers. These are just a few particularly egregious
cases that were hard to read and write, and error prone because
On 29/08/2018 12:13, Peter Eisentraut wrote:
> Here is a patch to change some struct initializations to use C99-style
> designated initializers. These are just a few particularly egregious
> cases that were hard to read and write, and error prone because of many
> similar ad
Here is a patch to change some struct initializations to use C99-style
designated initializers. These are just a few particularly egregious
cases that were hard to read and write, and error prone because of many
similar adjacent types.
(The PL/Python changes currently don't compile with Pyt
72 matches
Mail list logo
