On 04/09/2017 04:14 PM, Tom Lane wrote:
> Joe Conway writes:
>>> I turned on the buildfarm "keep" setting and looked at the diffs. The
>>> issue is that in there are a few places that do "SELECT ... FROM
>>> pg_seclabels ... ORDER BY ..." and when manually testing I get default
>>> database encodi
Joe Conway writes:
>> I turned on the buildfarm "keep" setting and looked at the diffs. The
>> issue is that in there are a few places that do "SELECT ... FROM
>> pg_seclabels ... ORDER BY ..." and when manually testing I get default
>> database encoding "UTF8" but with the buildfarm I get "SQL_AS
On 04/09/2017 03:01 PM, Joe Conway wrote:
> On 04/09/2017 02:49 PM, Andres Freund wrote:
>> On 2017-04-09 14:28:48 -0700, Joe Conway wrote:
>>> Interesting -- rhino is now failing. I tested a minute ago manually on
>>> the same buildfarm animal and it passed. I'm on it.
>>
>> The module for segpsq
On 04/09/2017 02:49 PM, Andres Freund wrote:
> On 2017-04-09 14:28:48 -0700, Joe Conway wrote:
>> Interesting -- rhino is now failing. I tested a minute ago manually on
>> the same buildfarm animal and it passed. I'm on it.
>
> The module for segpsql really needs to be improved so it logs
> regres
On 2017-04-09 14:28:48 -0700, Joe Conway wrote:
> Interesting -- rhino is now failing. I tested a minute ago manually on
> the same buildfarm animal and it passed. I'm on it.
The module for segpsql really needs to be improved so it logs
regression.diffs - iirc several other modules do.
Greetings,
On 04/09/2017 02:04 PM, Joe Conway wrote:
> On 04/08/2017 07:29 AM, Stephen Frost wrote:
>> * Joe Conway (m...@joeconway.com) wrote:
>>> On 04/07/2017 05:36 PM, Robert Haas wrote:
>>> > On Fri, Apr 7, 2017 at 5:22 PM, Joe Conway wrote:
>>> >> 1) commit the 0002 patch now before the feature freeze
On 04/08/2017 07:29 AM, Stephen Frost wrote:
> * Joe Conway (m...@joeconway.com) wrote:
>> On 04/07/2017 05:36 PM, Robert Haas wrote:
>> > On Fri, Apr 7, 2017 at 5:22 PM, Joe Conway wrote:
>> >> 1) commit the 0002 patch now before the feature freeze and follow up
>> >>with the regression test
Joe,
* Joe Conway (m...@joeconway.com) wrote:
> On 04/07/2017 05:36 PM, Robert Haas wrote:
> > On Fri, Apr 7, 2017 at 5:22 PM, Joe Conway wrote:
> >> 1) commit the 0002 patch now before the feature freeze and follow up
> >>with the regression test patch when ready in a couple of days
> >> 2)
On 04/07/2017 05:36 PM, Robert Haas wrote:
> On Fri, Apr 7, 2017 at 5:22 PM, Joe Conway wrote:
>> 1) commit the 0002 patch now before the feature freeze and follow up
>>with the regression test patch when ready in a couple of days
>> 2) hold off on both patches until ready
>> 3) push both patc
On Fri, Apr 7, 2017 at 5:22 PM, Joe Conway wrote:
> On 04/07/2017 11:37 AM, Mike Palmiotto wrote:
I found some missing bits in the 0002 patch -- new version attached.
Will wait on new regression tests before committing, but I expect we'll
have those by end of today and be able to co
On 04/07/2017 11:37 AM, Mike Palmiotto wrote:
>>> I found some missing bits in the 0002 patch -- new version attached.
>>> Will wait on new regression tests before committing, but I expect we'll
>>> have those by end of today and be able to commit the rest tomorrow.
>>
>> Attached are the regressio
On Thu, Apr 6, 2017 at 5:52 PM, Joe Conway wrote:
> On 04/06/2017 12:35 PM, Tom Lane wrote:
>> Joe Conway writes:
>>> Any thoughts on whether 0001a and 0001b ought to be backpatched? I'm
>>> thinking not given the lack of past complaints but it might make sense
>>> to do.
>>
>> I think 0001a abso
On 04/06/2017 12:35 PM, Tom Lane wrote:
> Joe Conway writes:
>> Any thoughts on whether 0001a and 0001b ought to be backpatched? I'm
>> thinking not given the lack of past complaints but it might make sense
>> to do.
>
> I think 0001a absolutely needs to be, because it is fixing what is really
>
Joe Conway writes:
> Any thoughts on whether 0001a and 0001b ought to be backpatched? I'm
> thinking not given the lack of past complaints but it might make sense
> to do.
I think 0001a absolutely needs to be, because it is fixing what is really
an ABI violation: sepgsql_needs_fmgr_hook is suppos
On 04/06/2017 08:29 AM, Tom Lane wrote:
> Joe Conway writes:
>> I'm going to push the attached in a few hours unless there is any
>> additional discussion. As stated above we'll do the regression changes
>> in a separate patch once that is sorted. I used Tom's approach and
>> comment wording for 0
Joe Conway writes:
> I'm going to push the attached in a few hours unless there is any
> additional discussion. As stated above we'll do the regression changes
> in a separate patch once that is sorted. I used Tom's approach and
> comment wording for 0001a.
Looks generally sane, but I noticed a g
On 04/05/2017 02:29 PM, Mike Palmiotto wrote:
> I'm going to hold the partition table regression changes for a
> separate patch and include some ORDER BY fixes. Will post tomorrow
>
> In the meantime, attached are the latest and greatest patches.
I'm going to push the attached in a few hours unle
On Wed, Apr 5, 2017 at 1:22 PM, Mike Palmiotto
wrote:
> On Wed, Apr 5, 2017 at 1:19 PM, Tom Lane wrote:
>> Peter Eisentraut writes:
>>> On 4/5/17 12:04, Tom Lane wrote:
Conclusion: Fedora's gcc is playing fast and loose somehow with the
command "#include "; that does not include the fi
On Wed, Apr 5, 2017 at 1:19 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 4/5/17 12:04, Tom Lane wrote:
>>> Conclusion: Fedora's gcc is playing fast and loose somehow with the
>>> command "#include "; that does not include the file
>>> you'd think it does, it does something magic inside th
Peter Eisentraut writes:
> On 4/5/17 12:04, Tom Lane wrote:
>> Conclusion: Fedora's gcc is playing fast and loose somehow with the
>> command "#include "; that does not include the file
>> you'd think it does, it does something magic inside the compiler.
>> The magic evidently includes not complai
On 4/5/17 12:04, Tom Lane wrote:
> Conclusion: Fedora's gcc is playing fast and loose somehow with the
> command "#include "; that does not include the file
> you'd think it does, it does something magic inside the compiler.
> The magic evidently includes not complaining about duplicate macro
> def
Andres Freund writes:
> GCC generally doesn't warn about macro redefinitions, if both
> definitions are equivalent.
But they're *not* equivalent. c.h has
#define true((bool) 1)
whereas so far as I can see the definition is just
#define true1
And if you put those two definitions toge
Peter Eisentraut writes:
> On 4/5/17 01:20, Tom Lane wrote:
>> $ cat test.c
>> typedef char bool;
>> typedef char bool;
>> $ gcc -c test.c
>> test.c:2: error: redefinition of typedef 'bool'
>> test.c:1: note: previous declaration of 'bool' was here
> But the above is not how the current code look
On April 5, 2017 9:04:00 AM PDT, Tom Lane wrote:
>Joe Conway writes:
>> On 04/04/2017 09:58 PM, Tom Lane wrote:
>>> Another issue is whether you won't get compiler complaints about
>>> redefinition of the "true" and "false" macros. But those would
>>> likely only be warnings, not flat-out erro
Joe Conway writes:
> On 04/04/2017 09:58 PM, Tom Lane wrote:
>> Another issue is whether you won't get compiler complaints about
>> redefinition of the "true" and "false" macros. But those would
>> likely only be warnings, not flat-out errors.
> I have not been able to generate warnings or error
On 4/5/17 01:20, Tom Lane wrote:
>> The complaint about bool is also just a warning.
>
> Really?
>
> $ cat test.c
> typedef char bool;
> typedef char bool;
> $ gcc -c test.c
> test.c:2: error: redefinition of typedef 'bool'
> test.c:1: note: previous declaration of 'bool' was here
>
> This is wi
On 04/04/2017 09:58 PM, Tom Lane wrote:
> I doubt that works at all, TBH. What I'd expect to happen with a
> typical compiler is a complaint about redefinition of typedef bool,
> because c.h already declared it and here this fragment is doing
> so again. It'd make sense to me to do
>
> + #ifdef
Andres Freund writes:
> On 2017-04-05 10:45:06 -0400, Tom Lane wrote:
>> Andres Freund writes:
>>> I wonder if there's any compiler that has _Bool/stdbool.h where it's not
>>> 1 byte sized. It's definitely not guaranteed by the standard.
>> Hm. I'd supposed that it'd be pretty common to make _B
Andres Freund writes:
> On 2017-04-05 10:48:27 -0400, Tom Lane wrote:
>> I'd really rather not. It might be safe here, because this code
>> only works on Linux anyway, but it's still a dangerous precedent.
> Well, what's the alternative for v10? There's already precedent btw.,
> cf plperl.h und
On 2017-04-05 10:48:27 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2017-03-31 20:23:39 -0400, Robert Haas wrote:
> >> 0001 has the problem that we have a firm rule against putting any
> >> #includes whatsoever before "postgres.h". This stdbool issue has come
> >> up before, though, and
On 2017-04-05 10:45:06 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2017-04-05 09:43:53 -0400, Tom Lane wrote:
> >> Yeah, I was just thinking about that. The core problem though is that
> >> we need the "bool" fields in the system catalog structs (or anyplace
> >> else that it represents
Andres Freund writes:
> On 2017-03-31 20:23:39 -0400, Robert Haas wrote:
>> 0001 has the problem that we have a firm rule against putting any
>> #includes whatsoever before "postgres.h". This stdbool issue has come
>> up before, though, and I fear we're going to need to do something
>> about it.
Andres Freund writes:
> On 2017-04-05 09:43:53 -0400, Tom Lane wrote:
>> Yeah, I was just thinking about that. The core problem though is that
>> we need the "bool" fields in the system catalog structs (or anyplace
>> else that it represents an on-disk bool datum) to be understood as
>> being 1 b
On 2017-03-31 20:23:39 -0400, Robert Haas wrote:
> On Fri, Mar 31, 2017 at 2:14 PM, Mike Palmiotto
> wrote:
> > Attached you will find two patches, which were rebased on master as of
> > 156d388 (applied with `git am --revert [patch file]`). The first gets
> > rid of some pesky compiler warnings a
On 2017-04-05 09:43:53 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I argued before that we should migrate to stdbool.h by default, because
> > it's only going to get more common. We already do so in a way for c++
> > compilers...
>
> Yeah, I was just thinking about that. The core problem
On Wed, Apr 5, 2017 at 12:58 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Apr 4, 2017 at 6:56 PM, Joe Conway wrote:
>>> Any objections?
>
>> I'm guessing Tom's going to have a strong feeling about whether 0001a
>> is the right way to address the stdbool issue,
>
> I will? [ looks ... ]
Andres Freund writes:
> I argued before that we should migrate to stdbool.h by default, because
> it's only going to get more common. We already do so in a way for c++
> compilers...
Yeah, I was just thinking about that. The core problem though is that
we need the "bool" fields in the system ca
On 2017-04-05 00:58:07 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Tue, Apr 4, 2017 at 6:56 PM, Joe Conway wrote:
> >> Any objections?
>
> > I'm guessing Tom's going to have a strong feeling about whether 0001a
> > is the right way to address the stdbool issue,
>
> I will? [ looks ...
Peter Eisentraut writes:
> On 4/5/17 00:58, Tom Lane wrote:
>> Another issue is whether you won't get compiler complaints about
>> redefinition of the "true" and "false" macros. But those would
>> likely only be warnings, not flat-out errors.
> The complaint about bool is also just a warning.
R
On 4/5/17 00:58, Tom Lane wrote:
> Another issue is whether you won't get compiler complaints about
> redefinition of the "true" and "false" macros. But those would
> likely only be warnings, not flat-out errors.
The complaint about bool is also just a warning.
--
Peter Eisentraut
Robert Haas writes:
> On Tue, Apr 4, 2017 at 6:56 PM, Joe Conway wrote:
>> Any objections?
> I'm guessing Tom's going to have a strong feeling about whether 0001a
> is the right way to address the stdbool issue,
I will? [ looks ... ] Yup, you're right.
I doubt that works at all, TBH. What I
On Tue, Apr 4, 2017 at 6:56 PM, Joe Conway wrote:
> On 04/04/2017 10:02 AM, Joe Conway wrote:
>> On 04/04/2017 09:55 AM, Mike Palmiotto wrote:
>>> After some discussion off-list, I've rebased and udpated the patches.
>>> Please see attached for further review.
>>
>> Thanks -- will have another loo
On 04/04/2017 10:02 AM, Joe Conway wrote:
> On 04/04/2017 09:55 AM, Mike Palmiotto wrote:
>> After some discussion off-list, I've rebased and udpated the patches.
>> Please see attached for further review.
>
> Thanks -- will have another look and test on a machine with selinux
> setup. Robert, did
On 04/04/2017 09:55 AM, Mike Palmiotto wrote:
> On Tue, Apr 4, 2017 at 10:19 AM, Joe Conway wrote:
>> On 04/04/2017 06:45 AM, Robert Haas wrote:
>>> On Mon, Apr 3, 2017 at 12:02 PM, Joe Conway wrote:
> 0002 looks extremely straightforward, but I wonder if we could get one
> of the people
On Tue, Apr 4, 2017 at 10:19 AM, Joe Conway wrote:
> On 04/04/2017 06:45 AM, Robert Haas wrote:
>> On Mon, Apr 3, 2017 at 12:02 PM, Joe Conway wrote:
0002 looks extremely straightforward, but I wonder if we could get one
of the people on this list who knows about sepgsql to have a look?
On 04/04/2017 06:45 AM, Robert Haas wrote:
> On Mon, Apr 3, 2017 at 12:02 PM, Joe Conway wrote:
>>> 0002 looks extremely straightforward, but I wonder if we could get one
>>> of the people on this list who knows about sepgsql to have a look?
>>> (Stephen Frost, Joe Conway, KaiGai Kohei...)
>>
>> W
On Mon, Apr 3, 2017 at 12:02 PM, Joe Conway wrote:
>> 0002 looks extremely straightforward, but I wonder if we could get one
>> of the people on this list who knows about sepgsql to have a look?
>> (Stephen Frost, Joe Conway, KaiGai Kohei...)
>
> Will have a look later today.
I think it is now to
On 03/31/2017 05:23 PM, Robert Haas wrote:
> On Fri, Mar 31, 2017 at 2:14 PM, Mike Palmiotto
> wrote:
>> Attached you will find two patches, which were rebased on master as of
>> 156d388 (applied with `git am --revert [patch file]`). The first gets
>> rid of some pesky compiler warnings and the se
On Fri, Mar 31, 2017 at 8:23 PM, Robert Haas wrote:
> On Fri, Mar 31, 2017 at 2:14 PM, Mike Palmiotto
> wrote:
>> Attached you will find two patches, which were rebased on master as of
>> 156d388 (applied with `git am --revert [patch file]`). The first gets
>> rid of some pesky compiler warnings
On Fri, Mar 31, 2017 at 2:14 PM, Mike Palmiotto
wrote:
> Attached you will find two patches, which were rebased on master as of
> 156d388 (applied with `git am --revert [patch file]`). The first gets
> rid of some pesky compiler warnings and the second implements the
> sepgsql handling of partitio
On Fri, Mar 31, 2017 at 2:14 PM, Mike Palmiotto
wrote:
> On Mon, Mar 27, 2017 at 12:09 PM, Mike Palmiotto
> wrote:
>> On Mon, Mar 27, 2017 at 11:46 AM, Robert Haas wrote:
>>>
>>> Note that sepgsql hasn't been updated to work with RLS yet, either,
>>> but we didn't regard that as an open item f
On Mon, Mar 27, 2017 at 12:09 PM, Mike Palmiotto
wrote:
> On Mon, Mar 27, 2017 at 11:46 AM, Robert Haas wrote:
>>
>> Note that sepgsql hasn't been updated to work with RLS yet, either,
>> but we didn't regard that as an open item for RLS, or if we did the
>> resolution was just to document it.
On Mon, Mar 27, 2017 at 11:46 AM, Robert Haas wrote:
> On Mon, Mar 27, 2017 at 11:22 AM, Mike Palmiotto
> wrote:
>> On Mon, Mar 27, 2017 at 10:47 AM, Robert Haas wrote:
>>> On Thu, Mar 9, 2017 at 9:47 AM, Stephen Frost wrote:
While going over the contrib modules, I noticed that sepgsql was
On Mon, Mar 27, 2017 at 11:22 AM, Mike Palmiotto
wrote:
> On Mon, Mar 27, 2017 at 10:47 AM, Robert Haas wrote:
>> On Thu, Mar 9, 2017 at 9:47 AM, Stephen Frost wrote:
>>> While going over the contrib modules, I noticed that sepgsql was not
>>> updated for partitioned tables. What that appears t
On Mon, Mar 27, 2017 at 10:47 AM, Robert Haas wrote:
> On Thu, Mar 9, 2017 at 9:47 AM, Stephen Frost wrote:
>> While going over the contrib modules, I noticed that sepgsql was not
>> updated for partitioned tables. What that appears to mean is that it's
>> not possible to define labels on partit
On Thu, Mar 9, 2017 at 9:47 AM, Stephen Frost wrote:
> While going over the contrib modules, I noticed that sepgsql was not
> updated for partitioned tables. What that appears to mean is that it's
> not possible to define labels on partitioned tables.
It works for me:
rhaas=# load 'dummy_seclab
Mike,
* Mike Palmiotto (mike.palmio...@crunchydata.com) wrote:
> On Thu, Mar 9, 2017 at 9:47 AM, Stephen Frost wrote:
> > While going over the contrib modules, I noticed that sepgsql was not
> > updated for partitioned tables. What that appears to mean is that it's
> > not possible to define lab
On Thu, Mar 9, 2017 at 9:47 AM, Stephen Frost wrote:
> Greetings,
>
> While going over the contrib modules, I noticed that sepgsql was not
> updated for partitioned tables. What that appears to mean is that it's
> not possible to define labels on partitioned tables. As I recall,
> accessing the
58 matches
Mail list logo
