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,
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 be fine. Any platforms where sizeof(bool)
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 being. I guess that you ha
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 holdin
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 involves macos older
>>> than 10.5 and Windo
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 platforms using MSVC versions older than
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 platforms have
>> > > si
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
Hi,
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
> > cares about going forward? The point of this patch is to ease
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 extensio
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 the ring, we have mor
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 changi
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 i
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 k
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 en
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.
--
Mic
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 p
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 well,
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 record_image_{eq,cmp}
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 contemporane
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 NUMERIC_ABB
On Thu, Jan 11, 2018 at 06:40:05PM -0500, Tom Lane wrote:
> 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
>
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(), which does run all pass-by-value va
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
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 to
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 bool8 should have identical Dat
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
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 way you can push 0001 shortl
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 will have an effect on the
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 bo
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 best
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 htt
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 c
On Wed, Dec 27, 2017 at 12:52:55PM -0500, Peter Eisentraut wrote:
> 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_consisten
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 eas
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
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 boo
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 be worth picking this up some time
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 unfixa
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.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DB
40 matches
Mail list logo