Re: [HACKERS] datistemplate of pg_database does not behave as per description in documentation

2014-06-18 Thread MauMau

From: Rajeev rastogi rajeev.rast...@huawei.com

Please find the attached patch with only documentation change.


I marked this as ready for committer.  The patch is good because it matches 
the description in the following page:


http://www.postgresql.org/docs/devel/static/manage-ag-templatedbs.html

Regards
MauMau



--
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] datistemplate of pg_database does not behave as per description in documentation

2014-06-18 Thread Fujii Masao
On Wed, Jun 18, 2014 at 7:47 PM, MauMau maumau...@gmail.com wrote:
 From: Rajeev rastogi rajeev.rast...@huawei.com

 Please find the attached patch with only documentation change.


 I marked this as ready for committer.  The patch is good because it matches
 the description in the following page:

 http://www.postgresql.org/docs/devel/static/manage-ag-templatedbs.html

ISTM that this patch has already been committed by Bruce. Please see
the commit 72590b3a69baaf24d1090a2c2ceb9181be34043e

Regards,

-- 
Fujii Masao


-- 
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] datistemplate of pg_database does not behave as per description in documentation

2014-06-18 Thread MauMau

From: Fujii Masao masao.fu...@gmail.com

On Wed, Jun 18, 2014 at 7:47 PM, MauMau maumau...@gmail.com wrote:
I marked this as ready for committer.  The patch is good because it 
matches

the description in the following page:

http://www.postgresql.org/docs/devel/static/manage-ag-templatedbs.html


ISTM that this patch has already been committed by Bruce. Please see
the commit 72590b3a69baaf24d1090a2c2ceb9181be34043e


Oh, the devel doc certainly reflects the change:

http://www.postgresql.org/docs/devel/static/catalog-pg-database.html

I marked this as committed.

I hope Magnus-san's enhancements to the CommitFest app will enable the 
CommitFest entry to be automatically updated at git commit.


Regards
MauMau




--
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] datistemplate of pg_database does not behave as per description in documentation

2014-04-01 Thread Rajeev rastogi
On 27 March 2014 17:16, Tom Lane Wrote:

 I agree we need to make the docs match the code, but changing behavior
 that's been like that for ten or fifteen years isn't the answer.

Sounds good.

Please find the attached patch with only documentation change.

Thanks and Regards,
Kumar Rajeev Rastogi




datistemplate_issueV2.patch
Description: datistemplate_issueV2.patch

-- 
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] datistemplate of pg_database does not behave as per description in documentation

2014-03-27 Thread Magnus Hagander
On Thu, Mar 27, 2014 at 9:12 AM, Rajeev rastogi
rajeev.rast...@huawei.comwrote:

  As per the documentation, datistemplate of pg_database is used in
 following way:



 datistemplate

 Bool

 If true then this database can be used in the TEMPLATE clause of CREATE
 DATABASE to create a new database as a clone of this one



 But current code does not behave in this manner.  Even if dbistemplate of
 database is false, still it allows to be used as template database.



 postgres=# select datname, datistemplate from pg_database;

   datname  | datistemplate

 ---+---

 template1 | t

 template0 | t

 *postgres  | f*

 (3 rows)



 *postgres=# create database tempdb template postgres;
 ---Actually this should fail.*

 *CREATE DATABASE*



 Though I am not sure if we have to modify source code to align the
 behavior with documentation or we need to change the documentation itself.

 To me it looks like code change will be better, so I am attaching the
 current patch with source code change.  After modification, result will be
 as follows:



 *postgres=# create database newtempdb template postgres;*

 *ERROR:  DB name postgres given as template is not a template database*



 Please provide your feedback.



AFAICT, the *only* thing datistemplate is used is to set parameters in
autovacuum.

So clearly we should do something. Changing the code that way carries the
risk of breaking applications (or at least DBA scripts) for no apparent
reason. I think it's better to document it.

However, that also raises a third option. We could just drop the idea if
datistemplate completely, and remove the column. Since clearly it's not
actually doing anything, and people seem to have been happy with that for a
while, why do we need it in the first place?


-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/


Re: [HACKERS] datistemplate of pg_database does not behave as per description in documentation

2014-03-27 Thread Stephen Frost
* Magnus Hagander (mag...@hagander.net) wrote:
 However, that also raises a third option. We could just drop the idea if
 datistemplate completely, and remove the column. Since clearly it's not
 actually doing anything, and people seem to have been happy with that for a
 while, why do we need it in the first place?

It's a bit of extra meta-data which can be nice to have (I know we use
that field for our own purposes..).  On the flip side, I've never liked
that you have to update pg_database to change it, so perhaps we should
get rid of it and remove that temptation.

The other field we regularly update in pg_database is datallowconn...
Would love to see that as an actual ALTER DATABASE command instead...

Thanks,

Stephen


signature.asc
Description: Digital signature


Re: [HACKERS] datistemplate of pg_database does not behave as per description in documentation

2014-03-27 Thread Tom Lane
Magnus Hagander mag...@hagander.net writes:
 On Thu, Mar 27, 2014 at 9:12 AM, Rajeev rastogi
 rajeev.rast...@huawei.comwrote:
 But current code does not behave in this manner.  Even if dbistemplate of
 database is false, still it allows to be used as template database.

 AFAICT, the *only* thing datistemplate is used is to set parameters in
 autovacuum.

Huh?  The code comment is perfectly clear:

/*
 * Permission check: to copy a DB that's not marked datistemplate, you
 * must be superuser or the owner thereof.
 */
if (!src_istemplate)
{
if (!pg_database_ownercheck(src_dboid, GetUserId()))
ereport(ERROR,
(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
 errmsg(permission denied to copy database \%s\,
dbtemplate)));
}

I agree we need to make the docs match the code, but changing behavior
that's been like that for ten or fifteen years isn't the answer.

(Changing code and failing to adjust the adjacent comment is even less
of an answer.)

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


Re: [HACKERS] datistemplate of pg_database does not behave as per description in documentation

2014-03-27 Thread Magnus Hagander
On Mar 27, 2014 12:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:

 Magnus Hagander mag...@hagander.net writes:
  On Thu, Mar 27, 2014 at 9:12 AM, Rajeev rastogi
  rajeev.rast...@huawei.comwrote:
  But current code does not behave in this manner.  Even if dbistemplate
of
  database is false, still it allows to be used as template database.

  AFAICT, the *only* thing datistemplate is used is to set parameters in
  autovacuum.

 Huh?  The code comment is perfectly clear:

 /*
  * Permission check: to copy a DB that's not marked datistemplate, you
  * must be superuser or the owner thereof.
  */
 if (!src_istemplate)
 {
 if (!pg_database_ownercheck(src_dboid, GetUserId()))
 ereport(ERROR,
 (errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
  errmsg(permission denied to copy database \%s\,
 dbtemplate)));
 }

 I agree we need to make the docs match the code, but changing behavior
 that's been like that for ten or fifteen years isn't the answer.

Hah, I hadn't done more than git grep for datistemplate :-) that's what I
get for taking shortcuts...

But yes, fixing  the documentation is what I advocate as well.

 (Changing code and failing to adjust the adjacent comment is even less
 of an answer.)

I didn't even look at the suggested patch..

/Magnus