Re: [HACKERS] taking stdbool.h into use

On 3/22/18 22:17, Peter Eisentraut wrote: > So after a day, only the old macOS PowerPC systems have sizeof(bool) == 4. And this is causing some problems in PL/Perl. I'll look into it. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA,

Re: [HACKERS] taking stdbool.h into use

On 3/21/18 07:48, Peter Eisentraut wrote: > On 3/21/18 01:51, Tom Lane wrote: >> Andres Freund writes: >>> On March 20, 2018 8:24:41 PM PDT, Michael Paquier >>> wrote: Yeah, I agree with that. Just not using stdbool.h in those cases ought to

Re: [HACKERS] taking stdbool.h into use

Michael Paquier writes: > On Wed, Mar 21, 2018 at 07:48:02AM -0400, Peter Eisentraut wrote: >> I've pushed the configure tests. Let's see what they say. > At least the buildfarm is green. Browsing the buildfarm logs manually > is kind of annoying for any normal human

Re: [HACKERS] taking stdbool.h into use

On Wed, Mar 21, 2018 at 07:48:02AM -0400, Peter Eisentraut wrote: > I've pushed the configure tests. Let's see what they say. At least the buildfarm is green. Browsing the buildfarm logs manually is kind of annoying for any normal human being. I guess that you have access to the database

Re: [HACKERS] taking stdbool.h into use

On 3/21/18 01:51, Tom Lane wrote: > Andres Freund writes: >> On March 20, 2018 8:24:41 PM PDT, Michael Paquier >> wrote: >>> Yeah, I agree with that. Just not using stdbool.h in those cases ought >>> to be fine. Any platforms where sizeof(bool) is 4

Re: [HACKERS] taking stdbool.h into use

Andres Freund writes: > On March 20, 2018 8:24:41 PM PDT, Michael Paquier wrote: >> Yeah, I agree with that. Just not using stdbool.h in those cases ought >> to be fine. Any platforms where sizeof(bool) is 4 involves macos older >> than 10.5 and Windows

Re: [HACKERS] taking stdbool.h into use

On March 20, 2018 8:24:41 PM PDT, Michael Paquier wrote: >On Tue, Mar 20, 2018 at 02:14:23PM -0700, Andres Freund wrote: >> On 2018-03-20 17:04:22 -0400, Peter Eisentraut wrote: >> > On 3/20/18 02:18, Tom Lane wrote: >> > > I think it'd be worth identifying exactly which

Re: [HACKERS] taking stdbool.h into use

On Tue, Mar 20, 2018 at 02:14:23PM -0700, Andres Freund wrote: > On 2018-03-20 17:04:22 -0400, Peter Eisentraut wrote: > > On 3/20/18 02:18, Tom Lane wrote: > > > I think it'd be worth identifying exactly which platforms have > > > sizeof(bool) different from 1. Are any of them things that anyone

Re: [HACKERS] taking stdbool.h into use

On 3/20/18 02:18, Tom Lane wrote: > I think it'd be worth identifying exactly which platforms have > sizeof(bool) different from 1. Are any of them things that anyone > cares about going forward? The point of this patch is to ease > future development of extensions, but it's unlikely any

Re: [HACKERS] taking stdbool.h into use

Michael Paquier writes: > On Tue, Mar 13, 2018 at 03:25:39PM -0400, Peter Eisentraut wrote: >> So I'm going back to my proposal from December, to just use stdbool.h >> when sizeof(bool) == 1, and add a static assertion to prevent other >> configurations. > So, on one side of

Re: [HACKERS] taking stdbool.h into use

On Tue, Mar 13, 2018 at 03:25:39PM -0400, Peter Eisentraut wrote: > After more digging, there are more problems with having a bool that is > not 1 byte. For example, pg_control has a bool field, so with a > different bool size, pg_control would be laid out differently. That > would require

Re: [HACKERS] taking stdbool.h into use

On 3/1/18 23:34, Michael Paquier wrote: > Indeed, this is wrong. Peter, why did you switch suddendly this patch > as ready for committer? The patch is waiting for your input as you > mentioned that the GIN portion of this patch series is not completely > baked yet. So I have switched the patch

Re: [HACKERS] taking stdbool.h into use

On Thu, Mar 01, 2018 at 02:28:54AM -0800, Andres Freund wrote: > On 2018-02-01 09:04:57 -0500, Peter Eisentraut wrote: >> I've been testing this a bit further and during a test setup with 4-byte >> bools I still got regression test failures related to GIN, so it doesn't >> seem quite ready. I'll

Re: [HACKERS] taking stdbool.h into use

On 2018-02-01 09:04:57 -0500, Peter Eisentraut wrote: > I've been testing this a bit further and during a test setup with 4-byte > bools I still got regression test failures related to GIN, so it doesn't > seem quite ready. I'll keep working on it. Are you planning to get this into v11? The CF

Re: [HACKERS] taking stdbool.h into use

On Thu, Feb 01, 2018 at 09:04:57AM -0500, Peter Eisentraut wrote: > I've been testing this a bit further and during a test setup with 4-byte > bools I still got regression test failures related to GIN, so it doesn't > seem quite ready. I'll keep working on it. Cool. Thanks for the update. --

Re: [HACKERS] taking stdbool.h into use

On 2/1/18 01:47, Michael Paquier wrote: > On Wed, Jan 24, 2018 at 03:44:04PM +0900, Michael Paquier wrote: >> Good catch. Coverage reports mark those areas as empty! Similarly the >> functions for record_* are mostly not used. Some tests could be added >> for them at the same time. The four error

Re: [HACKERS] taking stdbool.h into use

On Wed, Jan 24, 2018 at 03:44:04PM +0900, Michael Paquier wrote: > Good catch. Coverage reports mark those areas as empty! Similarly the > functions for record_* are mostly not used. Some tests could be added > for them at the same time. The four error paths of those functions are > tested as

Re: [HACKERS] taking stdbool.h into use

On Tue, Jan 23, 2018 at 11:33:56AM -0500, Peter Eisentraut wrote: > Here is a proposed patch set to clean this up. First, add some test > coverage for record_image_cmp. (There wasn't any, only for > record_image_eq as part of MV testing.) Then, remove the GET_ macros > from

Re: [HACKERS] taking stdbool.h into use

On 1/16/18 01:14, Michael Paquier wrote: >> I don't see it either. I think the actually useful parts of that patch >> were to declare record_image_cmp's result correctly as int rather than >> bool, and to cope with varlena fields of unequal size. Unfortunately >> there seems to be no

Re: [HACKERS] taking stdbool.h into use

On 1/11/18 17:01, Peter Eisentraut wrote: > Looking around where else they are used, the uses in numeric.c sure seem > like noops: > > #if SIZEOF_DATUM == 8 > #define NumericAbbrevGetDatum(X) ((Datum) SET_8_BYTES(X)) > #define DatumGetNumericAbbrev(X) ((int64) GET_8_BYTES(X)) > #define

Re: [HACKERS] taking stdbool.h into use

Peter Eisentraut writes: > That leaves the uses in rowtypes.c. Those were introduced as a > portability fix by commit 4cbb646334b. I'm curious why these are > necessary. The Datums they operate come from heap_deform_tuple(), which > gets them from fetchatt(),

Re: [HACKERS] taking stdbool.h into use

On 1/9/18 00:17, Michael Paquier wrote: >> * When a type narrower than Datum is stored in a Datum, we place it in the >> * low-order bits and are careful that the DatumGetXXX macro for it discards >> * the unused high-order bits (as opposed to, say, assuming they are zero). >> * This is needed

Re: [HACKERS] taking stdbool.h into use

On Sat, Dec 30, 2017 at 10:31:45AM -0500, Tom Lane wrote: > Surely bool and bool8 should have identical Datum representations, > so I'm not sure they need different DatumGet/GetDatum macros. [... refresh update ...] Yeah sure. I am a bit disturbed by the fact that DatumGetBool() enforces a case

Re: [HACKERS] taking stdbool.h into use

Michael Paquier writes: > So, looking at 0001 now... Shouldn't there be a DatumGetBool8(), with > the existing DatumGetBool() which should depend on the size of bool? I > can see that all the catalogs are correctly updated with bool8 in the > patch. Surely bool and

Re: [HACKERS] taking stdbool.h into use

On Sat, Dec 30, 2017 at 08:29:09AM +0900, Michael Paquier wrote: > On Fri, Dec 29, 2017 at 12:33:24PM -0500, Tom Lane wrote: >> It does make sense, probably, to push 0001-0003 first and see if >> anything turns up from that, then 0004. > > I have not looked at 0001 in details yet, which was going

Re: [HACKERS] taking stdbool.h into use

On Fri, Dec 29, 2017 at 12:33:24PM -0500, Tom Lane wrote: > Alvaro Herrera writes: > > Michael Paquier wrote: > >> I have looked at 0002 and 0003. Those look good to ship for me. > > > Yeah, I'd vote to push those right away to see what buildfarm has to > > say. That

Re: [HACKERS] taking stdbool.h into use

Alvaro Herrera writes: > Michael Paquier wrote: >> I have looked at 0002 and 0003. Those look good to ship for me. > Yeah, I'd vote to push those right away to see what buildfarm has to > say. That way you can push 0001 shortly after the dust settles (if > any), which

Re: [HACKERS] taking stdbool.h into use

Michael Paquier wrote: > On Thu, Dec 28, 2017 at 01:45:54PM -0500, Peter Eisentraut wrote: > > Here is a new patch set that picks up the best pieces of the recent > > discussions: We use stdbool.h if available, use bool8 in the system > > catalogs, define GinTernaryValue to be the same size as

Re: [HACKERS] taking stdbool.h into use

On Thu, Dec 28, 2017 at 01:45:54PM -0500, Peter Eisentraut wrote: > An earlier patch I posted defines GinTernaryValue to be the same size as > bool, accounting for different possible sizes of bool. Doh. I forgot this one. Yes that approach is fine. > Here is a new patch set that picks up the

Re: [HACKERS] taking stdbool.h into use

Here is a new patch set that picks up the best pieces of the recent discussions: We use stdbool.h if available, use bool8 in the system catalogs, define GinTernaryValue to be the same size as bool, and rewrite the GinNullCategory code to work without casting. -- Peter Eisentraut

Re: [HACKERS] taking stdbool.h into use

On 12/27/17 19:47, Michael Paquier wrote: >> For GinTernaryValue, I think it's easier to just make it the same size >> as bool, since it doesn't go onto disk. My earlier patch did that. I'm >> not sure it's worth adding more code to copy the array around. > But on prairiedog the sizeof bool and

Re: [HACKERS] taking stdbool.h into use

On 12/26/17 23:10, Michael Paquier wrote: > It would be nice to do something like that for GinTernaryValue in > tsginidx.c by mapping directly to GIN_FALSE and GIN_TRUE depending on > the input coming in gin_tsquery_consistent. The fix is more trivial > there. For GinTernaryValue, I think it's

Re: [HACKERS] taking stdbool.h into use

On Tue, Dec 26, 2017 at 02:00:47PM -0500, Peter Eisentraut wrote: > On 12/25/17 00:32, Michael Paquier wrote: > >> So here is a minimal patch set to perhaps wrap this up for the time > >> being. I have added static assertions that check the sizes of > >> GinNullCategory and GinTernaryValue, which

Re: [HACKERS] taking stdbool.h into use

On 12/25/17 00:32, Michael Paquier wrote: >> So here is a minimal patch set to perhaps wrap this up for the time >> being. I have added static assertions that check the sizes of >> GinNullCategory and GinTernaryValue, which I think are the two critical >> places that require compatibility with

Re: [HACKERS] taking stdbool.h into use

On Thu, Dec 21, 2017 at 1:02 AM, Peter Eisentraut wrote: > On 11/15/17 15:13, Peter Eisentraut wrote: >> I'm going to put this patch set as Returned With Feedback for now. The >> GinNullCategory issues look like they will need quite a bit of work. >> But it will

Re: [HACKERS] taking stdbool.h into use

On 11/15/17 15:13, Peter Eisentraut wrote: > I'm going to put this patch set as Returned With Feedback for now. The > GinNullCategory issues look like they will need quite a bit of work. > But it will be worth picking this up some time. I think the issue with GinNullCategory is practically