* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > On Friday, August 21, 2015, Tom Lane wrote:
> >> It is not really acceptable to leave roles hanging around after "make
> >> installcheck"; that would be a security hazard for the installation.
> >> Please drop them.
>
> > The onl
Stephen Frost writes:
> On Friday, August 21, 2015, Tom Lane wrote:
>> It is not really acceptable to leave roles hanging around after "make
>> installcheck"; that would be a security hazard for the installation.
>> Please drop them.
> The only ones which were left were intentionally all NOLOGIN
On Friday, August 21, 2015, Tom Lane wrote:
> Stephen Frost > writes:
> > On Friday, August 21, 2015, Piotr Stefaniak >
> > wrote:
> >> If I'm not mistaken, the roles introduced in this test are never
> dropped,
> >> which will cause the test to fail on consequent runs.
>
> > Ah, I was thinking
Stephen Frost writes:
> On Friday, August 21, 2015, Piotr Stefaniak
> wrote:
>> If I'm not mistaken, the roles introduced in this test are never dropped,
>> which will cause the test to fail on consequent runs.
> Ah, I was thinking there was a reason to not leave them around but couldn't
> think
On Friday, August 21, 2015, Piotr Stefaniak
wrote:
> If I'm not mistaken, the roles introduced in this test are never dropped,
> which will cause the test to fail on consequent runs.
>
Ah, I was thinking there was a reason to not leave them around but couldn't
think of it and liked the idea of t
* Andres Freund (and...@anarazel.de) wrote:
> I'd rather see those split into separate commits. Doing polishing and
> active bugs in one commit imo isn't a good idea if the polishing goes
> beyond a line or two.
>
> Otherwise this looks ok to me.
Done that way.
Thanks!
S
On Mon, Aug 17, 2015 at 8:01 AM, Andres Freund wrote:
> I'd rather see those split into separate commits. Doing polishing and
> active bugs in one commit imo isn't a good idea if the polishing goes
> beyond a line or two.
+1.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterpri
Hi,
On 2015-08-12 16:46:01 -0400, Stephen Frost wrote:
> From ab44660e9b8fc5b10f84ce6ba99a8340047ac8a5 Mon Sep 17 00:00:00 2001
> From: Stephen Frost
> Date: Wed, 12 Aug 2015 15:50:54 -0400
> Subject: [PATCH] In AlterRole, make bypassrls an int
>
> When reworking bypassrls in AlterRole to operat
On 08/13/2015 02:41 PM, Andres Freund wrote:
On 2015-08-13 14:28:58 +0300, Heikki Linnakangas wrote:
On 08/12/2015 03:46 PM, Stephen Frost wrote:
* Andres Freund (and...@anarazel.de) wrote:
On 2015-08-12 08:16:09 -0400, Stephen Frost wrote:
1) gin stores/queries some bools as GinTernaryValue.
On 2015-08-13 14:28:58 +0300, Heikki Linnakangas wrote:
> On 08/12/2015 03:46 PM, Stephen Frost wrote:
> >* Andres Freund (and...@anarazel.de) wrote:
> >>On 2015-08-12 08:16:09 -0400, Stephen Frost wrote:
> 1) gin stores/queries some bools as GinTernaryValue.
>
> Part of this is ea
On 2015-08-13 13:27:33 +0200, Michael Meskes wrote:
> > Playing around a bit lead to to find that this is caused by a wrong type
> > declaration in two places. 'isarray' is declared as bool instead of enum
> > ARRAY_TYPE in two places. This appears to be an oversight, perhaps
> > caused by the bool
On 08/12/2015 03:46 PM, Stephen Frost wrote:
* Andres Freund (and...@anarazel.de) wrote:
On 2015-08-12 08:16:09 -0400, Stephen Frost wrote:
1) gin stores/queries some bools as GinTernaryValue.
Part of this is easy to fix, just adjust GinScanKeyData->entryRes to
be a GinTernaryValue (it
> Playing around a bit lead to to find that this is caused by a wrong type
> declaration in two places. 'isarray' is declared as bool instead of enum
> ARRAY_TYPE in two places. This appears to be an oversight, perhaps
> caused by the boolean sounding name.
I vaguely remember that it used to be bo
* Andres Freund (and...@anarazel.de) wrote:
> I find that a somewhat ugly coding pattern, but since the rest of the
> function is written that way...
Agreed, but not going to change it at this point.
Would love feedback on the attached. I included the variable renames
discussed previously with N
Hi Michael,
I'm currently investigating some of our code cleanliness issues around
booleans. Turns out that ecpg fails if C99's _Bool is used as bool
instead of typedef char bool.
Playing around a bit lead to to find that this is caused by a wrong type
declaration in two places. 'isarray' is decl
* Andres Freund (and...@anarazel.de) wrote:
> On 2015-08-12 08:16:09 -0400, Stephen Frost wrote:
> > > 1) gin stores/queries some bools as GinTernaryValue.
> > >
> > >Part of this is easy to fix, just adjust GinScanKeyData->entryRes to
> > >be a GinTernaryValue (it's actually is compared a
On 2015-08-12 08:16:09 -0400, Stephen Frost wrote:
> > 1) gin stores/queries some bools as GinTernaryValue.
> >
> >Part of this is easy to fix, just adjust GinScanKeyData->entryRes to
> >be a GinTernaryValue (it's actually is compared against MAYBE).
> >
> >What I find slightly worrys
Andres,
* Andres Freund (and...@anarazel.de) wrote:
> Forcing our bool to be stdbool.h shows up a bunch of errors and
> warnings:
Wow.
> 1) gin stores/queries some bools as GinTernaryValue.
>
>Part of this is easy to fix, just adjust GinScanKeyData->entryRes to
>be a GinTernaryValue (it
On 2015-08-12 10:43:51 +0200, Andres Freund wrote:
> 3) The 'bypassrls' boolean in AlterUser() is queried strangely. There are two
> complaints:
>
> boolbypassrls = -1;
>
> it's a boolean.
>
> else if (authform->rolbypassrls || bypassrls >= 0)
> {
>
19 matches
Mail list logo
