On Thu, Nov 21, 2019 at 04:50:22AM +, Smith, Peter wrote:
> I thought this submission actually started out very popular, but
> then support slowly eroded, and currently seems headed towards a
> likely rejection.
Yeah, it seems to me that this tends to be a rejection, and the thread
has actuall
Hi Hackers.
This submission seems to have stalled.
Please forgive this post - I am unsure if the submission process expects me to
come to defence of my own patch for one last gasp, or if I am supposed to just
sit back and watch it die a slow death of a thousand cuts.
I thought this submission
Hi,
On 2019-11-12 14:17:42 +0900, Michael Paquier wrote:
> On Tue, Oct 22, 2019 at 04:13:03PM +0530, Amit Kapila wrote:
> > Hmm, but then what is your suggestion for existing code that uses {0}.
> > If we reject this patch and leave the current code as it is, there is
> > always a risk of some peo
On Tue, Oct 22, 2019 at 04:13:03PM +0530, Amit Kapila wrote:
> Hmm, but then what is your suggestion for existing code that uses {0}.
> If we reject this patch and leave the current code as it is, there is
> always a risk of some people using {0} and others using memset which
> will lead to further
On Tue, Oct 22, 2019 at 12:35 AM Tom Lane wrote:
>
> Stephen Frost writes:
> > * Joe Nelson (j...@begriffs.com) wrote:
> >> If it's being put behind a macro then *stylistically* it shouldn't
> >> matter whether {} or {0} is chosen, right? In which case {0} would
> >> be a better choice because it
On 2019-10-21 15:04:36 -0400, Tom Lane wrote:
> There is a general solution that works across platforms; it's called
> memset() and it's what we're using today. I'm beginning to think that
> we should just reject this patch. It's certainly not enough of an
> improvement to justify the amount of d
Stephen Frost writes:
> * Joe Nelson (j...@begriffs.com) wrote:
>> If it's being put behind a macro then *stylistically* it shouldn't
>> matter whether {} or {0} is chosen, right? In which case {0} would
>> be a better choice because it's supported everywhere.
> The problem with {0} in the first
Greetings,
* Joe Nelson (j...@begriffs.com) wrote:
> > Is it possible to define the macro to be {} where supported and {0}
> > where needed? Something like:
>
> If it's being put behind a macro then *stylistically* it shouldn't
> matter whether {} or {0} is chosen, right? In which case {0} would
> Is it possible to define the macro to be {} where supported and {0}
> where needed? Something like:
If it's being put behind a macro then *stylistically* it shouldn't
matter whether {} or {0} is chosen, right? In which case {0} would
be a better choice because it's supported everywhere.
On Mon, 21 Oct 2019 at 11:46, Chapman Flack wrote:
>
> I would favor {} in a heartbeat if it were standard, because that
> sucker is an idiom.
>
> Failing that, though, I think I still favor the macro, because
> question (1) seems less fuzzy than question (2), and on "clear",
> the macro wins.
>
On 10/21/19 11:25 AM, Joe Nelson wrote:
> we have the
> INIT_ALL_ELEMS_ZERO macro to avoid (2). However the more I look at the
> code using that macro the less I like it. The {0} initializer is more
> idiomatic.
If faced with the two questions:
1. which of a or b is more "clear" ?
2. which of a o
> > I don't understand why this is an issue worth deviating from the
> > standard for.
>
> Because this use and the way the standard is defined in this case is
> confusing and could lead later hackers to misunderstand what's going on
> and end up creating bugs-
The two possible misunderstandings
On Sat, Oct 19, 2019 at 9:14 PM Stephen Frost wrote:
>
> * Andres Freund (and...@anarazel.de) wrote:
>
> > Especially not when the person suggesting to do so isn't
> > even doing the leg work to estimate the portability issues.
>
> I figured it was common knowledge that gcc/clang supported it just
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2019-10-18 09:03:31 -0400, Stephen Frost wrote:
> > * Chapman Flack (c...@anastigmatix.net) wrote:
> > > On 10/18/19 08:18, Stephen Frost wrote:
> > > > I realize that I need to don some fireproof gear for suggesting this,
> > > > but I r
Hi,
On 2019-10-18 09:03:31 -0400, Stephen Frost wrote:
> * Chapman Flack (c...@anastigmatix.net) wrote:
> > On 10/18/19 08:18, Stephen Frost wrote:
> > > I realize that I need to don some fireproof gear for suggesting this,
> > > but I really wonder how much fallout we'd have from just allowing {}
Greetings,
* Chapman Flack (c...@anastigmatix.net) wrote:
> On 10/18/19 08:18, Stephen Frost wrote:
> > I realize that I need to don some fireproof gear for suggesting this,
> > but I really wonder how much fallout we'd have from just allowing {} to
> > be used.. It's about a billion[1] times cle
On 10/18/19 08:18, Stephen Frost wrote:
> I realize that I need to don some fireproof gear for suggesting this,
> but I really wonder how much fallout we'd have from just allowing {} to
> be used.. It's about a billion[1] times cleaner and more sensible than
> using {0} and doesn't create a depend
Greetings,
* Thomas Munro (thomas.mu...@gmail.com) wrote:
> On Tue, Oct 8, 2019 at 11:09 PM Amit Kapila wrote:
> > I am personally still in the camp of people advocating the use of
> > macro for this purpose. It is quite possible after reading your
> > points, some people might change their opin
On Thu, Oct 17, 2019 at 4:58 PM Kyotaro Horiguchi
wrote:
>
> At Thu, 17 Oct 2019 16:30:02 +0900, Michael Paquier
> wrote in
> > On Thu, Oct 17, 2019 at 06:37:11PM +1300, Thomas Munro wrote:
> > > -1 for these macros.
> > >
> > > These are basic facts about the C language. I hope C eventually
>
At Thu, 17 Oct 2019 16:30:02 +0900, Michael Paquier wrote
in
> On Thu, Oct 17, 2019 at 06:37:11PM +1300, Thomas Munro wrote:
> > -1 for these macros.
> >
> > These are basic facts about the C language. I hope C eventually
> > supports {} like C++, so that you don't have to think hard about
> >
On Thu, Oct 17, 2019 at 06:37:11PM +1300, Thomas Munro wrote:
> -1 for these macros.
>
> These are basic facts about the C language. I hope C eventually
> supports {} like C++, so that you don't have to think hard about
> whether the first member is another struct, and recursively so … but
> sinc
On Tue, Oct 8, 2019 at 11:09 PM Amit Kapila wrote:
> On Sat, Oct 5, 2019 at 3:10 AM Andres Freund wrote:
> > On 2019-10-04 17:08:29 -0400, Tom Lane wrote:
> > > Andres Freund writes:
> > > > On 2019-10-04 16:31:29 -0400, Bruce Momjian wrote:
> > > >> Yeah, it is certainly weird that you have to
On Tue, Oct 8, 2019 at 4:43 AM Smith, Peter wrote:
>
> From: Amit Kapila Sent: Friday, 4 October 2019 4:50
> PM
>
> >>How about I just define them both the same?
> >>#define INIT_ALL_ELEMS_ZERO {0}
> >>#define INIT_ALL_ELEMS_FALSE{0}
> >
> >I think using one define would be preferred, bu
On Sat, Oct 5, 2019 at 3:10 AM Andres Freund wrote:
>
> On 2019-10-04 17:08:29 -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > On 2019-10-04 16:31:29 -0400, Bruce Momjian wrote:
> > >> Yeah, it is certainly weird that you have to assign the first array
> > >> element to get the rest to be
From: Amit Kapila Sent: Friday, 4 October 2019 4:50 PM
>>How about I just define them both the same?
>>#define INIT_ALL_ELEMS_ZERO {0}
>>#define INIT_ALL_ELEMS_FALSE {0}
>
>I think using one define would be preferred, but you can wait and see if
>others prefer defining different macros fo
Hi,
On 2019-10-04 17:08:29 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2019-10-04 16:31:29 -0400, Bruce Momjian wrote:
> >> Yeah, it is certainly weird that you have to assign the first array
> >> element to get the rest to be zeros. By using a macro, we can document
> >> this behavior
Andres Freund writes:
> On 2019-10-04 16:31:29 -0400, Bruce Momjian wrote:
>> Yeah, it is certainly weird that you have to assign the first array
>> element to get the rest to be zeros. By using a macro, we can document
>> this behavior in one place.
> IDK, to me this seems like something one ju
Hi,
On 2019-10-04 16:31:29 -0400, Bruce Momjian wrote:
> On Fri, Oct 4, 2019 at 02:05:41PM -0400, Chapman Flack wrote:
> > On 10/4/19 1:44 PM, Ashwin Agrawal wrote:
> >
> > > macro exist in first place will be hard to remember. So, irrespective
> > > in long run, {0} might get used in code and h
On Fri, Oct 4, 2019 at 02:05:41PM -0400, Chapman Flack wrote:
> On 10/4/19 1:44 PM, Ashwin Agrawal wrote:
>
> > macro exist in first place will be hard to remember. So, irrespective
> > in long run, {0} might get used in code and hence seems better
> > to just use {0} from start itself instead of
On 10/4/19 1:44 PM, Ashwin Agrawal wrote:
> macro exist in first place will be hard to remember. So, irrespective
> in long run, {0} might get used in code and hence seems better
> to just use {0} from start itself instead of macro/wrapper on top.
>
> Plus, even if someone starts out with thought
On Fri, Oct 4, 2019 at 8:49 AM Tom Lane wrote:
> Jacob Champion writes:
> > On Fri, Oct 4, 2019 at 7:51 AM Tom Lane wrote:
> >> I concur with Joe here. The reason why some of the existing
> >> memset's use "false" is for symmetry with other places where we use
> >> "memset(p, true, n)" to set
Jacob Champion writes:
> On Fri, Oct 4, 2019 at 7:51 AM Tom Lane wrote:
>> I concur with Joe here. The reason why some of the existing
>> memset's use "false" is for symmetry with other places where we use
>> "memset(p, true, n)" to set an array of bools to all-true.
> Why introduce a macro at
On Fri, Oct 4, 2019 at 7:51 AM Tom Lane wrote:
> I concur with Joe here. The reason why some of the existing
> memset's use "false" is for symmetry with other places where we use
> "memset(p, true, n)" to set an array of bools to all-true. That
> coding is unfortunately a bit dubious --- it woul
Joe Nelson writes:
> One might argue that INIT_ALL_ELEMS_FALSE as a synonym for
> INIT_ALL_ELEMS_ZERO is good for readability in the same way that "false"
> is for 0. However I want to avoid creating the impression that there is,
> or can be, a collection of INIT_ALL_ELEMS_xxx macros invoking diff
Amit Kapila wrote:
> > How about I just define them both the same?
> > #define INIT_ALL_ELEMS_ZERO {0}
> > #define INIT_ALL_ELEMS_FALSE{0}
>
> I think using one define would be preferred, but you can wait and see
> if others prefer defining different macros for the same thing.
+1 on using
On Fri, Oct 4, 2019 at 12:10 PM Smith, Peter
wrote:
> From: Tom Lane Sent: Friday, 4 October 2019 2:08 PM
>
> >> #define INIT_ALL_ELEMS_ZERO {0}
> >> #define INIT_ALL_ELEMS_FALSE {false}
>
> >I would say that's 100% wrong. The entire point here is that it's
> memset-equivalent, and therefore w
From: Tom Lane Sent: Friday, 4 October 2019 2:08 PM
>> #define INIT_ALL_ELEMS_ZERO {0}
>> #define INIT_ALL_ELEMS_FALSE {false}
>I would say that's 100% wrong. The entire point here is that it's
>memset-equivalent, and therefore writes zeroes, regardless of what the
>datatype is.
I agree i
"Smith, Peter" writes:
> From: Amit Kapila Sent: Friday, 4 October 2019 1:32
> PM
>> Also, if we want to pursue, do we want to use INIT_ALL_ZEROES for bool
>> arrays as well?
> FYI - In case it went unnoticed - my last patch addresses this by defining 2
> macros:
> #define INIT_ALL_ELEMS_Z
From: Amit Kapila Sent: Friday, 4 October 2019 1:32 PM
> Also, if we want to pursue, do we want to use INIT_ALL_ZEROES for bool
>arrays as well?
FYI - In case it went unnoticed - my last patch addresses this by defining 2
macros:
#define INIT_ALL_ELEMS_ZERO {0}
#define INIT_ALL_ELEMS_FAL
On Wed, Oct 2, 2019 at 9:16 PM Tom Lane wrote:
> Joe Nelson writes:
> > Isaac Morland wrote:
> >> I hope you'll forgive a noob question. Why does the "After"
> >> initialization for the boolean array have {0} rather than {false}?
>
> > I think using a value other than {0} potentially gives the i
-Original Message-
From: Tom Lane Sent: Thursday, 3 October 2019 1:46 AM
> Right. I think that in general it's bad practice for an initializer to not
> specify all fields/elements of the target.
> It is okay in the specific case that we're substituting for a memset(..., 0,
> ...).
> Pe
On Wed, Oct 02, 2019 at 02:55:39PM -0400, Tom Lane wrote:
> Mark Dilger writes:
>> (I'm sitting on a few patches until v12 goes out the door from some
>> conversations with you several months ago, and perhaps I'll include a
>> patch for this cleanup, too, when time comes for v13 patch sets to be
Mark Dilger writes:
> (I'm sitting on a few patches until v12 goes out the door from some
> conversations with you several months ago, and perhaps I'll include a
> patch for this cleanup, too, when time comes for v13 patch sets to be
> submitted.
That would be now. We already ran one CF for v
On 10/2/19 11:02 AM, Tom Lane wrote:
Mark Dilger writes:
On 10/2/19 8:46 AM, Tom Lane wrote:
Right. I think that in general it's bad practice for an initializer
to not specify all fields/elements of the target.
There are numerous locations in the code that raise warnings when
-Wmissing-
Mark Dilger writes:
> On 10/2/19 8:46 AM, Tom Lane wrote:
>> Right. I think that in general it's bad practice for an initializer
>> to not specify all fields/elements of the target.
> There are numerous locations in the code that raise warnings when
> -Wmissing-field-initializers is handed to gc
On 10/2/19 8:46 AM, Tom Lane wrote:
Joe Nelson writes:
Isaac Morland wrote:
I hope you'll forgive a noob question. Why does the "After"
initialization for the boolean array have {0} rather than {false}?
I think using a value other than {0} potentially gives the incorrect
impression that
> If so, I don't suppose it's possible to give empty braces:
>
> bool nulls[Natts_pg_attribute] = {};
GNU does add this capability as a nonstandard language extension, but
according to the C99 standard, no.
On Wed, 2 Oct 2019 at 11:34, Joe Nelson wrote:
> Isaac Morland wrote:
> > I hope you'll forgive a noob question. Why does the "After"
> > initialization for the boolean array have {0} rather than {false}?
>
> I think using a value other than {0} potentially gives the incorrect
> impression that t
Joe Nelson writes:
> Isaac Morland wrote:
>> I hope you'll forgive a noob question. Why does the "After"
>> initialization for the boolean array have {0} rather than {false}?
> I think using a value other than {0} potentially gives the incorrect
> impression that the value is used for *all* eleme
Isaac Morland wrote:
> I hope you'll forgive a noob question. Why does the "After"
> initialization for the boolean array have {0} rather than {false}?
I think using a value other than {0} potentially gives the incorrect
impression that the value is used for *all* elements of the
array/structure,
From: Amit Kapila Sent: Wednesday, 2 October 2019
9:42 AM
> I don't have any strong opinion on this, but I would mildly prefer to
> initialize boolean array with false just for the sake of readability (we
> generally initializing booleans with false).
Done. Please see attached updated patch.
From: Amit Kapila Sent: Tuesday, 1 October 2019 8:12
PM
> +1. This seems like an improvement. I can review and take this forward
> unless there are objections from others.
FYI - I created a Commitfest entry for this here:
https://commitfest.postgresql.org/25/2290/
Kind Regards
--
Peter Smi
On Wed, Oct 2, 2019 at 4:53 AM Smith, Peter
wrote:
> From: Isaac Morland Sent: Tuesday, 1 October
> 2019 11:32 PM
>
> >Typical Example:
> >Before:
> >Datum values[Natts_pg_attribute];
> >boolnulls[Natts_pg_attribute];
> >...
> >memset(values,
From: Isaac Morland Sent: Tuesday, 1 October 2019
11:32 PM
>Typical Example:
>Before:
> Datum values[Natts_pg_attribute];
> bool nulls[Natts_pg_attribute];
> ...
> memset(values, 0, sizeof(values));
> memset(nulls, false, sizeof(nulls));
>A
On Wed, Oct 2, 2019 at 5:49 AM Andres Freund wrote:
> On 2019-10-01 12:17:08 -0400, Tom Lane wrote:
> > Note though that InsertPgAttributeTuple uses memset(), while some of
> > these other places use MemSet(). The code I see being generated for
> > MemSet() is also the same(!) on clang, but it is
Hi,
On 2019-10-01 12:17:08 -0400, Tom Lane wrote:
> FYI, I checked into whether this would result in worse generated code.
> In the one place I checked (InsertPgAttributeTuple, which hopefully
> is representative), I got *exactly the same* assembly code before
> and after, on both a somewhat-aging
Bruce Momjian writes:
>>> On Tue, Oct 1, 2019 at 1:25 PM Smith, Peter
>>> wrote:
There are lots of tuple operations where arrays of values and flags are
being passed.
Typically these arrays are being previously initialised 0/false by memset.
By modifying code to use C99 desi
On Tue, Oct 1, 2019 at 08:40:26AM -0400, Andrew Dunstan wrote:
>
> On 10/1/19 6:12 AM, Amit Kapila wrote:
> > On Tue, Oct 1, 2019 at 1:25 PM Smith, Peter
> > wrote:
> >> Dear Hackers,
> >>
> >> I have identified some OSS code which maybe can make use of C99 designated
> >> initialisers for nul
On Tue, 1 Oct 2019 at 03:55, Smith, Peter
wrote:
> Typical Example:
> Before:
> Datum values[Natts_pg_attribute];
> boolnulls[Natts_pg_attribute];
> ...
> memset(values, 0, sizeof(values));
> memset(nulls, false, sizeof(nulls));
> Aft
On 10/1/19 6:12 AM, Amit Kapila wrote:
> On Tue, Oct 1, 2019 at 1:25 PM Smith, Peter
> wrote:
>> Dear Hackers,
>>
>> I have identified some OSS code which maybe can make use of C99 designated
>> initialisers for nulls/values arrays.
>>
>> ~
>>
>> Background:
>> There are lots of tuple operatio
On Tue, Oct 1, 2019 at 1:25 PM Smith, Peter wrote:
>
> Dear Hackers,
>
> I have identified some OSS code which maybe can make use of C99 designated
> initialisers for nulls/values arrays.
>
> ~
>
> Background:
> There are lots of tuple operations where arrays of values and flags are being
> pass
61 matches
Mail list logo
