date:20141024

Re: [HACKERS] Function array_agg(array)

2014-10-24 Thread Pavel Stehule

2014-10-25 8:33 GMT+02:00 Pavel Stehule :

>
>
> 2014-10-25 8:19 GMT+02:00 Ali Akbar :
>
>> 2014-10-25 10:29 GMT+07:00 Ali Akbar :
>>
>>> I fixed small issue in regress tests and I enhanced tests for varlena
 types and null values.
>>>
>>> Thanks.
>>>
>>> it is about 15% faster than original implementation.
>>>
>>> 15% faster than array_agg(scalar)? I haven't verify the performance, but
>>> because the internal array data and null bitmap is copied as-is, that will
>>> be faster.
>>>
>>> 2014-10-25 1:51 GMT+07:00 Pavel Stehule :
>>>
 Hi Ali

>>>
 I checked a code. I am thinking so code organization is not good.
 accumArrayResult is too long now. makeMdArrayResult will not work, when
 arrays was joined (it is not consistent now). I don't like a usage of
 state->is_array_accum in array_userfunc.c -- it is signal of wrong
 wrapping.

>>> Yes, i was thinking the same. Attached WIP patch to reorganizate the
>>> code. makeMdArrayResult works now, with supplied arguments act as override
>>> from default values calculated from ArrayBuildStateArray.
>>>
>>> In array_userfunc.c, because we don't want to override ndims, dims and
>>> lbs, i copied array_agg_finalfn and only change the call to
>>> makeMdArrayResult (we don't uses makeArrayResult because we want to set
>>> release to false). Another alternative is to create new
>>> makeArrayResult-like function that has parameter bool release.
>>>
>>
>> adding makeArrayResult1 (do you have better name for this?), that accepts
>> bool release parameter. array_agg_finalfn becomes more clean, and no
>> duplicate code in array_agg_anyarray_finalfn.
>>
>
>  makeArrayResult1 - I have no better name now
>
> I found one next minor detail.
>
> you reuse a array_agg_transfn function. Inside is a message
> "array_agg_transfn called in non-aggregate context". It is not correct for
> array_agg_anyarray_transfn
>
> probably specification dim and lbs in array_agg_finalfn is useless, when
> you expect a natural result. A automatic similar to
> array_agg_anyarray_finalfn should work there too.
>
> makeMdArrayResultArray and appendArrayDatum  should be marked as "static"
>

I am thinking so change of makeArrayResult is wrong. It is developed for 1D
array. When we expect somewhere ND result now, then we should to use
makeMdArrayResult there. So makeArrayResult should to return 1D array in
all cases. Else a difference between makeArrayResult and makeMdArrayResult
hasn't big change and we have a problem with naming.

Regards

Pavel



>
>
>>
>>> next question: there is function array_append(anyarray, anyelement).
 Isn't time to define array_append(anyarray, anyarray) now?

>>>
>>> There is array_cat(anyarray, anyarray):
>>>
>>> /*-
>>>  * array_cat :
>>>  * concatenate two nD arrays to form an nD array, or
>>>  * push an (n-1)D array onto the end of an nD array
>>>
>>>  
>>> *
>>>  */
>>>
>>
>> Regards,
>> --
>> Ali Akbar
>>
>
>

Re: [HACKERS] Function array_agg(array)

2014-10-24 Thread Pavel Stehule

2014-10-25 8:19 GMT+02:00 Ali Akbar :

> 2014-10-25 10:29 GMT+07:00 Ali Akbar :
>
>> I fixed small issue in regress tests and I enhanced tests for varlena
>>> types and null values.
>>
>> Thanks.
>>
>> it is about 15% faster than original implementation.
>>
>> 15% faster than array_agg(scalar)? I haven't verify the performance, but
>> because the internal array data and null bitmap is copied as-is, that will
>> be faster.
>>
>> 2014-10-25 1:51 GMT+07:00 Pavel Stehule :
>>
>>> Hi Ali
>>>
>>
>>> I checked a code. I am thinking so code organization is not good.
>>> accumArrayResult is too long now. makeMdArrayResult will not work, when
>>> arrays was joined (it is not consistent now). I don't like a usage of
>>> state->is_array_accum in array_userfunc.c -- it is signal of wrong
>>> wrapping.
>>>
>> Yes, i was thinking the same. Attached WIP patch to reorganizate the
>> code. makeMdArrayResult works now, with supplied arguments act as override
>> from default values calculated from ArrayBuildStateArray.
>>
>> In array_userfunc.c, because we don't want to override ndims, dims and
>> lbs, i copied array_agg_finalfn and only change the call to
>> makeMdArrayResult (we don't uses makeArrayResult because we want to set
>> release to false). Another alternative is to create new
>> makeArrayResult-like function that has parameter bool release.
>>
>
> adding makeArrayResult1 (do you have better name for this?), that accepts
> bool release parameter. array_agg_finalfn becomes more clean, and no
> duplicate code in array_agg_anyarray_finalfn.
>

 makeArrayResult1 - I have no better name now

I found one next minor detail.

you reuse a array_agg_transfn function. Inside is a message
"array_agg_transfn called in non-aggregate context". It is not correct for
array_agg_anyarray_transfn

probably specification dim and lbs in array_agg_finalfn is useless, when
you expect a natural result. A automatic similar to
array_agg_anyarray_finalfn should work there too.

makeMdArrayResultArray and appendArrayDatum  should be marked as "static"


>
>> next question: there is function array_append(anyarray, anyelement).
>>> Isn't time to define array_append(anyarray, anyarray) now?
>>>
>>
>> There is array_cat(anyarray, anyarray):
>>
>> /*-
>>  * array_cat :
>>  * concatenate two nD arrays to form an nD array, or
>>  * push an (n-1)D array onto the end of an nD array
>>
>>  
>> *
>>  */
>>
>
> Regards,
> --
> Ali Akbar
>

Re: [HACKERS] Function array_agg(array)

2014-10-24 Thread Ali Akbar

2014-10-25 10:29 GMT+07:00 Ali Akbar :

> I fixed small issue in regress tests and I enhanced tests for varlena
>> types and null values.
>
> Thanks.
>
> it is about 15% faster than original implementation.
>
> 15% faster than array_agg(scalar)? I haven't verify the performance, but
> because the internal array data and null bitmap is copied as-is, that will
> be faster.
>
> 2014-10-25 1:51 GMT+07:00 Pavel Stehule :
>
>> Hi Ali
>>
>
>> I checked a code. I am thinking so code organization is not good.
>> accumArrayResult is too long now. makeMdArrayResult will not work, when
>> arrays was joined (it is not consistent now). I don't like a usage of
>> state->is_array_accum in array_userfunc.c -- it is signal of wrong
>> wrapping.
>>
> Yes, i was thinking the same. Attached WIP patch to reorganizate the code.
> makeMdArrayResult works now, with supplied arguments act as override from
> default values calculated from ArrayBuildStateArray.
>
> In array_userfunc.c, because we don't want to override ndims, dims and
> lbs, i copied array_agg_finalfn and only change the call to
> makeMdArrayResult (we don't uses makeArrayResult because we want to set
> release to false). Another alternative is to create new
> makeArrayResult-like function that has parameter bool release.
>

adding makeArrayResult1 (do you have better name for this?), that accepts
bool release parameter. array_agg_finalfn becomes more clean, and no
duplicate code in array_agg_anyarray_finalfn.


> next question: there is function array_append(anyarray, anyelement). Isn't
>> time to define array_append(anyarray, anyarray) now?
>>
>
> There is array_cat(anyarray, anyarray):
>
> /*-
>  * array_cat :
>  * concatenate two nD arrays to form an nD array, or
>  * push an (n-1)D array onto the end of an nD array
>
>  *
>  */
>

Regards,
-- 
Ali Akbar
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 7e5bcd9..f59738a 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -12046,6 +12046,22 @@ NULL baz(3 rows)
  
   

+array_agg
+   
+   array_agg(anyarray)
+  
+  
+   any
+  
+  
+   the same array type as input type
+  
+  input arrays, aggregated into higher-order multidimesional array. Rejects NULL and empty array as input.
+ 
+
+ 
+  
+   
 average


diff --git a/doc/src/sgml/syntax.sgml b/doc/src/sgml/syntax.sgml
index 2f0680f..8c182a4 100644
--- a/doc/src/sgml/syntax.sgml
+++ b/doc/src/sgml/syntax.sgml
@@ -2238,6 +2238,11 @@ SELECT ARRAY(SELECT oid FROM pg_proc WHERE proname LIKE 'bytea%');
  array
 ---
  {2011,1954,1948,1952,1951,1244,1950,2005,1949,1953,2006,31,2412,2413}
+
+SELECT ARRAY(SELECT array(select i) FROM generate_series(1,5) a(i));
+ array
+---
+ {{1},{2},{3},{4},{5}}
 (1 row)
 
The subquery must return a single column. The resulting
diff --git a/src/backend/nodes/nodeFuncs.c b/src/backend/nodes/nodeFuncs.c
index 41e973b..0261fcb 100644
--- a/src/backend/nodes/nodeFuncs.c
+++ b/src/backend/nodes/nodeFuncs.c
@@ -108,12 +108,16 @@ exprType(const Node *expr)
 	type = exprType((Node *) tent->expr);
 	if (sublink->subLinkType == ARRAY_SUBLINK)
 	{
-		type = get_array_type(type);
-		if (!OidIsValid(type))
-			ereport(ERROR,
-	(errcode(ERRCODE_UNDEFINED_OBJECT),
-	 errmsg("could not find array type for data type %s",
-			format_type_be(exprType((Node *) tent->expr);
+		if (!OidIsValid(get_element_type(type)))
+		{
+			/* not array, so check for its array type */
+			type = get_array_type(type);
+			if (!OidIsValid(type))
+ereport(ERROR,
+		(errcode(ERRCODE_UNDEFINED_OBJECT),
+		 errmsg("could not find array type for data type %s",
+format_type_be(exprType((Node *) tent->expr);
+		}
 	}
 }
 else if (sublink->subLinkType == MULTIEXPR_SUBLINK)
@@ -139,12 +143,16 @@ exprType(const Node *expr)
 	type = subplan->firstColType;
 	if (subplan->subLinkType == ARRAY_SUBLINK)
 	{
-		type = get_array_type(type);
-		if (!OidIsValid(type))
-			ereport(ERROR,
-	(errcode(ERRCODE_UNDEFINED_OBJECT),
-	 errmsg("could not find array type for data type %s",
-	format_type_be(subplan->firstColType;
+		if (!OidIsValid(get_element_type(type)))
+		{
+			/* not array, so check for its array type */
+			type = get_array_type(type);
+			if (!OidIsValid(type))
+ereport(ERROR,
+		(errcode(ERRCODE_UNDEFINED_OBJECT),
+		 errmsg("could not find array type for data type %s",
+		format_type_be(subplan->firstColType;
+		}
 	}
 }
 else i

Re: [HACKERS] Wait free LW_SHARED acquisition - v0.2

2014-10-24 Thread Amit Kapila

On Fri, Oct 24, 2014 at 4:05 PM, Andres Freund 
wrote:
>
> On 2014-10-24 15:59:30 +0530, Amit Kapila wrote:
> > > > and w.r.t performance it can lead extra
> > > > function call, few checks and I think in some cases even can
> > > > acquire/release spinlock.
> > >
> > > I fail to see how that could be the case.
> >
> > Won't it happen incase first backend sets releaseOK to true and another
> > backend which tries to wakeup waiters on lock will acquire spinlock
> > and tries to release the waiters.
>
> Sure, that can happen.
> > > And again, this is code that's
> > > only executed around a couple syscalls. And the cacheline will be
> > > touched around there *anyway*.
> >
> > Sure, but I think syscalls are required in case we need to wake any
> > waiter.
>
> It won't wake up a waiter if there's none on the list.

Yeap, but still it will acquire/release spinlock.

> > > > > And it'd be a pretty pointless
> > > > > behaviour, leading to useless increased contention. The only time
it'd
> > > > > make sense for X to be woken up is when it gets run faster than
the S
> > > > > processes.
> > > >
> > > > Do we get any major benefit by changing the logic of waking up
waiters?
> > >
> > > Yes.
> >
> > I think one downside I could see of new strategy is that the chance of
> > Exclusive waiter to take more time before getting woked up is increased
> > as now it will by pass Exclusive waiters in queue.
>
> Note that that *already* happens for any *new* shared locker that comes
> in. It doesn't really make sense to have share lockers queued behind the
> exclusive locker if others just go in front of it anyway.

Yeah, but I think it is difficult to avoid that behaviour as even when it
wakes
Exclusive locker, some new shared locker can comes in and acquire the
lock before Exclusive locker.

I think it is difficult to say what is the best waking strategy, as
priority for
Exclusive lockers is not clearly defined incase of LWLocks.


With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

Re: [HACKERS] Function array_agg(array)

2014-10-24 Thread Ali Akbar

>
> I fixed small issue in regress tests and I enhanced tests for varlena
> types and null values.

Thanks.

it is about 15% faster than original implementation.

15% faster than array_agg(scalar)? I haven't verify the performance, but
because the internal array data and null bitmap is copied as-is, that will
be faster.

2014-10-25 1:51 GMT+07:00 Pavel Stehule :

> Hi Ali
>

> I checked a code. I am thinking so code organization is not good.
> accumArrayResult is too long now. makeMdArrayResult will not work, when
> arrays was joined (it is not consistent now). I don't like a usage of
> state->is_array_accum in array_userfunc.c -- it is signal of wrong
> wrapping.
>
Yes, i was thinking the same. Attached WIP patch to reorganizate the code.
makeMdArrayResult works now, with supplied arguments act as override from
default values calculated from ArrayBuildStateArray.

In array_userfunc.c, because we don't want to override ndims, dims and lbs,
i copied array_agg_finalfn and only change the call to makeMdArrayResult
(we don't uses makeArrayResult because we want to set release to false).
Another alternative is to create new makeArrayResult-like function that has
parameter bool release.


> next question: there is function array_append(anyarray, anyelement). Isn't
> time to define array_append(anyarray, anyarray) now?
>

There is array_cat(anyarray, anyarray):
/*-
 * array_cat :
 * concatenate two nD arrays to form an nD array, or
 * push an (n-1)D array onto the end of an nD array
 *
 */

Regards,
--
Ali Akbar
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 7e5bcd9..f59738a 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -12046,6 +12046,22 @@ NULL baz(3 rows)
  
   

+array_agg
+   
+   array_agg(anyarray)
+  
+  
+   any
+  
+  
+   the same array type as input type
+  
+  input arrays, aggregated into higher-order multidimesional array. Rejects NULL and empty array as input.
+ 
+
+ 
+  
+   
 average


diff --git a/doc/src/sgml/syntax.sgml b/doc/src/sgml/syntax.sgml
index 2f0680f..8c182a4 100644
--- a/doc/src/sgml/syntax.sgml
+++ b/doc/src/sgml/syntax.sgml
@@ -2238,6 +2238,11 @@ SELECT ARRAY(SELECT oid FROM pg_proc WHERE proname LIKE 'bytea%');
  array
 ---
  {2011,1954,1948,1952,1951,1244,1950,2005,1949,1953,2006,31,2412,2413}
+
+SELECT ARRAY(SELECT array(select i) FROM generate_series(1,5) a(i));
+ array
+---
+ {{1},{2},{3},{4},{5}}
 (1 row)
 
The subquery must return a single column. The resulting
diff --git a/src/backend/nodes/nodeFuncs.c b/src/backend/nodes/nodeFuncs.c
index 41e973b..0261fcb 100644
--- a/src/backend/nodes/nodeFuncs.c
+++ b/src/backend/nodes/nodeFuncs.c
@@ -108,12 +108,16 @@ exprType(const Node *expr)
 	type = exprType((Node *) tent->expr);
 	if (sublink->subLinkType == ARRAY_SUBLINK)
 	{
-		type = get_array_type(type);
-		if (!OidIsValid(type))
-			ereport(ERROR,
-	(errcode(ERRCODE_UNDEFINED_OBJECT),
-	 errmsg("could not find array type for data type %s",
-			format_type_be(exprType((Node *) tent->expr);
+		if (!OidIsValid(get_element_type(type)))
+		{
+			/* not array, so check for its array type */
+			type = get_array_type(type);
+			if (!OidIsValid(type))
+ereport(ERROR,
+		(errcode(ERRCODE_UNDEFINED_OBJECT),
+		 errmsg("could not find array type for data type %s",
+format_type_be(exprType((Node *) tent->expr);
+		}
 	}
 }
 else if (sublink->subLinkType == MULTIEXPR_SUBLINK)
@@ -139,12 +143,16 @@ exprType(const Node *expr)
 	type = subplan->firstColType;
 	if (subplan->subLinkType == ARRAY_SUBLINK)
 	{
-		type = get_array_type(type);
-		if (!OidIsValid(type))
-			ereport(ERROR,
-	(errcode(ERRCODE_UNDEFINED_OBJECT),
-	 errmsg("could not find array type for data type %s",
-	format_type_be(subplan->firstColType;
+		if (!OidIsValid(get_element_type(type)))
+		{
+			/* not array, so check for its array type */
+			type = get_array_type(type);
+			if (!OidIsValid(type))
+ereport(ERROR,
+		(errcode(ERRCODE_UNDEFINED_OBJECT),
+		 errmsg("could not find array type for data type %s",
+		format_type_be(subplan->firstColType;
+		}
 	}
 }
 else if (subplan->subLinkType == MULTIEXPR_SUBLINK)
diff --git a/src/backend/optimizer/plan/subselect.c b/src/backend/optimizer/plan/subselect.c
index 3e7dc85..8fc8b49 100644
--- a/src/backend/optimizer/plan/subselect.c
+++ b/src/backend/optimizer/plan/subselect.c
@@ -668,10 +668,16 @@ build_subplan(Pla

Re: [HACKERS] How ugly would this be? (ALTER DATABASE)

2014-10-24 Thread Robert Haas

On Fri, Oct 24, 2014 at 7:37 PM, Jim Nasby  wrote:
> ISTM that the multiple-databases-per-backend issue is the huge hang-up here.
> Maybe there's some way that could be hacked around if you're just
> re-jiggering a bunch of catalog stuff (assuming you lock users out of both
> databases while you're doing that), but if you were going to go to that
> extent perhaps it'd be better to just support cross-database access in a
> single backend...

Good luck with that.  It's probably as hard or harder than making the
backend multi-threaded, which is itself harder than any project a
reasonable person will undertake any time in the forseeable future.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] security barrier INSERT

2014-10-24 Thread Brightwell, Adam

Drew,


> IMHO this is nonintuitive, the intuitive behavior of a security_barrier
> view should be to forbid inserting rows that can’t appear in the view.
>

Isn't that what WITH CHECK OPTION is meant to accomplish?

-Adam



-- 
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com

[HACKERS] security barrier INSERT

2014-10-24 Thread Drew Crawford

Hi guys, I’m seeing some non-intuitive behavior with the new updateable 
security barrier views in 9.4.  Below is the behavior of 9.4b3:

> =# create table widget ( id integer);
> CREATE TABLE
> =# create view widget_sb WITH (security_barrier=true) AS SELECT * from widget 
> where id = 22;
> CREATE VIEW
> =# insert into widget_sb (id) values (23);
> INSERT 0 1
> =# select * from widget;
>  id 
> 
>  23
> (1 row)


I think the insert should fail, since the view can only contain widgets with id 
= 22, and the widget being inserted has id 23.  In reality, the insert to the 
behind table succeeds as shown above, although it still remains absent from the 
view:

> =# select * from widget_sb;
>  id 
> 
> (0 rows)


IMHO this is nonintuitive, the intuitive behavior of a security_barrier view 
should be to forbid inserting rows that can’t appear in the view.

Have I missed something fundamental here?

Drew

Re: [HACKERS] Comment in outfunc.c

2014-10-24 Thread Tom Lane

Tatsuo Ishii  writes:
> I saw this comment in _outQuery() in outfuncs.c:

>   WRITE_ENUM_FIELD(commandType, CmdType);
>   WRITE_ENUM_FIELD(querySource, QuerySource);
>   /* we intentionally do not print the queryId field */
>   WRITE_BOOL_FIELD(canSetTag);

> What is the resoning behind the comment?

We don't want the queryId copied when a view/rule is reloaded,
since there's no guarantee that the algorithm for computing it
is stable for the life of a PG major version.  Instead it's reset
to zero on reload, and any plugins that care can recompute it.

I suppose we could print it anyway and then ignore it on reload
but what's the point of that?

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Comment in outfunc.c

2014-10-24 Thread Tatsuo Ishii

Hi,

I saw this comment in _outQuery() in outfuncs.c:

WRITE_ENUM_FIELD(commandType, CmdType);
WRITE_ENUM_FIELD(querySource, QuerySource);
/* we intentionally do not print the queryId field */
WRITE_BOOL_FIELD(canSetTag);

What is the resoning behind the comment?

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Comment patch for bgworker.c

2014-10-24 Thread Jim Nasby


The comment for the BackgroundWorkerSlot structure tripped me up reviewing 
Robert's background worker patch; it made it clear that you need to use a 
memory barrier before setting in_use, but normally you'd never need to worry 
about that because RegisterDynamicBackgroundWorker() handles it for you. Patch 
adds a comment to that effect.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
diff --git a/src/backend/postmaster/bgworker.c 
b/src/backend/postmaster/bgworker.c
index 85a3b3a..e81dbc1 100644
--- a/src/backend/postmaster/bgworker.c
+++ b/src/backend/postmaster/bgworker.c
@@ -55,7 +55,8 @@ slist_headBackgroundWorkerList = 
SLIST_STATIC_INIT(BackgroundWorkerList);
  * responsibility of the postmaster.  Regular backends may no longer modify it,
  * but the postmaster may examine it.  Thus, a backend initializing a slot
  * must fully initialize the slot - and insert a write memory barrier - before
- * marking it as in use.
+ * marking it as in use. Note that RegisterDynamicBackgroundWorker() handles
+ * in_use correctly for you.
  *
  * As an exception, however, even when the slot is in use, regular backends
  * may set the 'terminate' flag for a slot, telling the postmaster not

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] superuser() shortcuts

2014-10-24 Thread Jim Nasby

On 10/23/14, 6:23 PM, Alvaro Herrera wrote:

Brightwell, Adam wrote:

If we were to make it consistent and use the old wording, what do you
think about providing an "errhint" as well?

Perhaps for example in slotfuncs.c#pg_create_physical_replication_stot:

errmsg - "permission denied to create physical replication slot"
errhint - "You must be superuser or replication role to use replication slots."

Sure.

As I started looking at this, there are multiple other places where
these types of error messages occur (opclasscmds.c, user.c,
postinit.c, miscinit.c are just a few), not just around the changes in
this patch. If we change them in one place, wouldn't it be best to
change them in the rest? If that is the case, I'm afraid that might
distract from the purpose of this patch. Perhaps, if we want to
change them, then that should be submitted as a separate patch?

Yeah. I'm just saying that maybe this patch should adopt whatever
wording we agree to, not that we need to change other places. On the
other hand, since so many other places have adopted the different
wording, maybe there's a reason for it and if so, does anybody know what
it is. But I have to say that it does look inconsistent to me.

Keep in mind that originally the ONLY special permissions "thing" we had was rolsuper.
Now we also have replication, maybe some others, and there's discussion of adding a special
"backup role".

In other words, the situation is a lot more complex than it used to be. So if
cleanup is done here, it would be best to try and account for this new stuff.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

96 matches

Mail list logo