Re: [HACKERS] Can pg_dump make use of CURRENT/SESSION_USER

2015-09-03 Thread Fabrízio de Royes Mello 
On Thu, Sep 3, 2015 at 8:16 AM, Andres Freund  wrote:
>
> On 2015-08-25 22:01:51 +0900, Michael Paquier wrote:
> > Seeing no activity in the last couple of months for this patch that
> > had reviews, it is now marked as returned with feedback.
>
> Fabrizio, you after the above moved the patch to next commitfest,
> without a new patch or a additional discussion. Why? Just dragging
> patches through commitfest justincreases the work for a number of people
> (this round me) without a benefit, so that's really not a good idea.
>

My intention was move to next commitfest and finish the "rework", but I
didn't finish it due some other professional priorities.

Sorry by the noise.


> I'm marking the patch as returned with feedback again. Once there's a
> new patch we can deal with it in the appropriate commitfest.
>

Ok.


Regards,

--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
>> Timbira: http://www.timbira.com.br
>> Blog: http://fabriziomello.github.io
>> Linkedin: http://br.linkedin.com/in/fabriziomello
>> Twitter: http://twitter.com/fabriziomello
>> Github: http://github.com/fabriziomello

Re: [HACKERS] Can pg_dump make use of CURRENT/SESSION_USER

2015-09-03 Thread Andres Freund 
On 2015-08-25 22:01:51 +0900, Michael Paquier wrote:
> Seeing no activity in the last couple of months for this patch that
> had reviews, it is now marked as returned with feedback.

Fabrizio, you after the above moved the patch to next commitfest,
without a new patch or a additional discussion. Why? Just dragging
patches through commitfest justincreases the work for a number of people
(this round me) without a benefit, so that's really not a good idea.

I'm marking the patch as returned with feedback again. Once there's a
new patch we can deal with it in the appropriate commitfest.

Greetings,

Andres Freund


-- 
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] Can pg_dump make use of CURRENT/SESSION_USER

2015-08-25 Thread Michael Paquier 
On Thu, Apr 30, 2015 at 2:04 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
 Fabrízio de Royes Mello wrote:

 I have this idea:

 1) Add an ObjectAddress field to CommentStmt struct an set it in gram.y

 2) In the CommentObject check if CommentStmt-address is
 InvalidObjectAddress then call get_object_address else use it

 For DDL deparsing purposes, it seems important that the affected object
 address can be reproduced somehow.  I think pg_get_object_address()
 should be considered, as well as the object_address test.

 If we do as you propose, we would have to deparse
 COMMENT ON CURRENT DATABASE IS 'foo'
 as
   COMMENT ON DATABASE whatever_the_name_is IS 'foo'

 which is not a fatal objection but doesn't seem all that great.

Seeing no activity in the last couple of months for this patch that
had reviews, it is now marked as returned with feedback.
-- 
Michael


-- 
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] Can pg_dump make use of CURRENT/SESSION_USER

2015-04-29 Thread Alvaro Herrera 
Fabrízio de Royes Mello wrote:
 
 Looking at the patch again I realize the code is very ugly, so I'll rework
 the patch.

Yes, I think get_object_address should figure out what to do with the
representation of CURRENT DATABASE directly, rather than having the
COMMENT code morph from that into a list containing the name of the
current database.  Please see about changing SECURITY LABEL at the same
time, if only to make sure that the representation is sane.

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training  Services


-- 
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] Can pg_dump make use of CURRENT/SESSION_USER

2015-04-29 Thread Fabrízio de Royes Mello 
On Wed, Apr 29, 2015 at 1:14 PM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:

 Fabrízio de Royes Mello wrote:
 
  Looking at the patch again I realize the code is very ugly, so I'll
rework
  the patch.

 Yes, I think get_object_address should figure out what to do with the
 representation of CURRENT DATABASE directly, rather than having the
 COMMENT code morph from that into a list containing the name of the
 current database.  Please see about changing SECURITY LABEL at the same
 time, if only to make sure that the representation is sane.


I have this idea:

1) Add an ObjectAddress field to CommentStmt struct an set it in gram.y

2) In the CommentObject check if CommentStmt-address is
InvalidObjectAddress then call get_object_address else use it

Thoughts?

--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
 Timbira: http://www.timbira.com.br
 Blog: http://fabriziomello.github.io
 Linkedin: http://br.linkedin.com/in/fabriziomello
 Twitter: http://twitter.com/fabriziomello
 Github: http://github.com/fabriziomello

Re: [HACKERS] Can pg_dump make use of CURRENT/SESSION_USER

2015-04-29 Thread Alvaro Herrera 
Fabrízio de Royes Mello wrote:

 I have this idea:
 
 1) Add an ObjectAddress field to CommentStmt struct an set it in gram.y
 
 2) In the CommentObject check if CommentStmt-address is
 InvalidObjectAddress then call get_object_address else use it

For DDL deparsing purposes, it seems important that the affected object
address can be reproduced somehow.  I think pg_get_object_address()
should be considered, as well as the object_address test.

If we do as you propose, we would have to deparse
COMMENT ON CURRENT DATABASE IS 'foo'
as
  COMMENT ON DATABASE whatever_the_name_is IS 'foo'

which is not a fatal objection but doesn't seem all that great.

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training  Services


-- 
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] Can pg_dump make use of CURRENT/SESSION_USER

2015-04-28 Thread Fabrízio de Royes Mello 
On Tue, Apr 28, 2015 at 1:07 PM, Fabrízio de Royes Mello 
fabriziome...@gmail.com wrote:


 On Tue, Apr 28, 2015 at 9:38 AM, Robert Haas robertmh...@gmail.com
wrote:
 
  On Sat, Apr 25, 2015 at 8:05 AM, Fabrízio de Royes Mello
  fabriziome...@gmail.com wrote:
 If we ever implement something like

 COMMENT ON CURRENT_DATABASE IS ...

 it will be useful, because you will be able to restore a dump
into
 another database and have the comment apply to the target
database.
   
I think it's simple to implement, but how about pg_dump... we need
to
add
new option (like --use-current-database) or am I missing something
?
  
   I think we'd just change it to use the new syntax, full stop.  I see
   no need for an option.
  
   I'm returning on this...
  
   What's the reasonable syntaxes?
  
   COMMENT ON CURRENT DATABASE IS 'text';
  
   or
  
   COMMENT ON DATABASE { CURRENT_DATABASE | object_name } IS 'text';
 
  The second one would require making CURRENT_DATABASE a reserved
  keyword, and I'm not keen to create any more of those.  I like the
  first one.  The other alternative that may be worth considering is:
 
  COMMENT ON CURRENT_DATABASE IS 'text';
 
  That doesn't require making CURRENT_DATABASE a reserved keyword, but
  it does require making it a keyword, and it doesn't look very SQL-ish.
  Still, we have a bunch of other CURRENT_FOO keywords.
 
  But I'm inclined to stick with your first proposal.
 

 Attached the patch to support COMMENT ON CURRENT DATABASE IS ...
(including pg_dump).

 On my next spare time I'll send the ALTER ROLE ... IN CURRENT DATABASE
patch.


Looking at the patch again I realize the code is very ugly, so I'll rework
the patch.

Regards,

--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
 Timbira: http://www.timbira.com.br
 Blog: http://fabriziomello.github.io
 Linkedin: http://br.linkedin.com/in/fabriziomello
 Twitter: http://twitter.com/fabriziomello
 Github: http://github.com/fabriziomello

Re: [HACKERS] Can pg_dump make use of CURRENT/SESSION_USER

2015-04-28 Thread Fabrízio de Royes Mello 
On Tue, Apr 28, 2015 at 9:38 AM, Robert Haas robertmh...@gmail.com wrote:

 On Sat, Apr 25, 2015 at 8:05 AM, Fabrízio de Royes Mello
 fabriziome...@gmail.com wrote:
If we ever implement something like
   
COMMENT ON CURRENT_DATABASE IS ...
   
it will be useful, because you will be able to restore a dump into
another database and have the comment apply to the target
database.
  
   I think it's simple to implement, but how about pg_dump... we need to
   add
   new option (like --use-current-database) or am I missing something ?
 
  I think we'd just change it to use the new syntax, full stop.  I see
  no need for an option.
 
  I'm returning on this...
 
  What's the reasonable syntaxes?
 
  COMMENT ON CURRENT DATABASE IS 'text';
 
  or
 
  COMMENT ON DATABASE { CURRENT_DATABASE | object_name } IS 'text';

 The second one would require making CURRENT_DATABASE a reserved
 keyword, and I'm not keen to create any more of those.  I like the
 first one.  The other alternative that may be worth considering is:

 COMMENT ON CURRENT_DATABASE IS 'text';

 That doesn't require making CURRENT_DATABASE a reserved keyword, but
 it does require making it a keyword, and it doesn't look very SQL-ish.
 Still, we have a bunch of other CURRENT_FOO keywords.

 But I'm inclined to stick with your first proposal.


Attached the patch to support COMMENT ON CURRENT DATABASE IS ...
(including pg_dump).

On my next spare time I'll send the ALTER ROLE ... IN CURRENT DATABASE
patch.

Regards,

--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
 Timbira: http://www.timbira.com.br
 Blog: http://fabriziomello.github.io
 Linkedin: http://br.linkedin.com/in/fabriziomello
 Twitter: http://twitter.com/fabriziomello
 Github: http://github.com/fabriziomello
diff --git a/doc/src/sgml/ref/comment.sgml b/doc/src/sgml/ref/comment.sgml
index 656f5aa..b080106 100644
--- a/doc/src/sgml/ref/comment.sgml
+++ b/doc/src/sgml/ref/comment.sgml
@@ -30,6 +30,7 @@ COMMENT ON
   CONSTRAINT replaceable class=PARAMETERconstraint_name/replaceable ON replaceable class=PARAMETERtable_name/replaceable |
   CONSTRAINT replaceable class=PARAMETERconstraint_name/replaceable ON DOMAIN replaceable class=PARAMETERdomain_name/replaceable |
   CONVERSION replaceable class=PARAMETERobject_name/replaceable |
+  CURRENT DATABASE |
   DATABASE replaceable class=PARAMETERobject_name/replaceable |
   DOMAIN replaceable class=PARAMETERobject_name/replaceable |
   EXTENSION replaceable class=PARAMETERobject_name/replaceable |
@@ -92,6 +93,11 @@ COMMENT ON
   /para
 
   para
+   The CURRENT DATABASE means the comment will be applied to the database
+   where the command is executed.
+  /para
+
+  para
 Comments can be viewed using applicationpsql/application's
 command\d/command family of commands.
 Other user interfaces to retrieve comments can be built atop
@@ -301,6 +307,7 @@ COMMENT ON COLUMN my_table.my_column IS 'Employee ID number';
 COMMENT ON CONVERSION my_conv IS 'Conversion to UTF8';
 COMMENT ON CONSTRAINT bar_col_cons ON bar IS 'Constrains column col';
 COMMENT ON CONSTRAINT dom_col_constr ON DOMAIN dom IS 'Constrains col of domain';
+COMMENT ON CURRENT DATABASE IS 'Current Database Comment';
 COMMENT ON DATABASE my_database IS 'Development Database';
 COMMENT ON DOMAIN my_domain IS 'Email Address Domain';
 COMMENT ON EXTENSION hstore IS 'implements the hstore data type';
diff --git a/src/backend/commands/comment.c b/src/backend/commands/comment.c
index 6d8c006..db9b3c5 100644
--- a/src/backend/commands/comment.c
+++ b/src/backend/commands/comment.c
@@ -43,25 +43,29 @@ CommentObject(CommentStmt *stmt)
 	ObjectAddress address = InvalidObjectAddress;
 
 	/*
-	 * When loading a dump, we may see a COMMENT ON DATABASE for the old name
-	 * of the database.  Erroring out would prevent pg_restore from completing
-	 * (which is really pg_restore's fault, but for now we will work around
-	 * the problem here).  Consensus is that the best fix is to treat wrong
-	 * database name as a WARNING not an ERROR; hence, the following special
-	 * case.  (If the length of stmt-objname is not 1, get_object_address
+	 * If the length of stmt-objname is 1 then the COMMENT ON DATABASE command
+	 * was used, else COMMENT ON CURRENT DATABASE was used instead.
+	 * (If the length of stmt-objname is not 1, get_object_address
 	 * will throw an error below; that's OK.)
 	 */
-	if (stmt-objtype == OBJECT_DATABASE  list_length(stmt-objname) == 1)
+	if (stmt-objtype == OBJECT_DATABASE)
 	{
-		char	   *database = strVal(linitial(stmt-objname));
-
-		if (!OidIsValid(get_database_oid(database, true)))
+		/* COMMENT ON DATABASE name */
+		if (list_length(stmt-objname) == 1)
 		{
-			ereport(WARNING,
-	(errcode(ERRCODE_UNDEFINED_DATABASE),
-	 errmsg(database \%s\ does not exist, database)));
-			return address;
+			char	   *database = strVal(linitial(stmt-objname));
+
+			if (!OidIsValid(get_database_oid(database, true)))
+			{
+ereport(WARNING,
+

Re: [HACKERS] Can pg_dump make use of CURRENT/SESSION_USER

2015-04-25 Thread Fabrízio de Royes Mello 
On Wed, Mar 18, 2015 at 2:24 PM, Robert Haas robertmh...@gmail.com wrote:

 On Wed, Mar 18, 2015 at 1:23 PM, Fabrízio de Royes Mello
 fabriziome...@gmail.com wrote:
   If we ever implement something like
  
   COMMENT ON CURRENT_DATABASE IS ...
  
   it will be useful, because you will be able to restore a dump into
   another database and have the comment apply to the target database.
 
  I think it's simple to implement, but how about pg_dump... we need to
add
  new option (like --use-current-database) or am I missing something ?

 I think we'd just change it to use the new syntax, full stop.  I see
 no need for an option.


I'm returning on this...

What's the reasonable syntaxes?

COMMENT ON CURRENT DATABASE IS 'text';

or

COMMENT ON DATABASE { CURRENT_DATABASE | object_name } IS 'text';


   (Also, I wonder about
   ALTER USER foo IN DATABASE current_database ...
   because that will let us dump per-database user options too.)
 
  +1 for both of those ideas.
 


ALTER ROLE { role_specification | ALL } [ IN CURRENT DATABASE ] SET/RESET
...

or

ALTER ROLE { role_specification | ALL } [ IN { CURRENT DATABASE | DATABASE
database_name } ] SET/RESET ...


Regards,

--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
 Timbira: http://www.timbira.com.br
 Blog: http://fabriziomello.github.io
 Linkedin: http://br.linkedin.com/in/fabriziomello
 Twitter: http://twitter.com/fabriziomello
 Github: http://github.com/fabriziomello

Re: [HACKERS] Can pg_dump make use of CURRENT/SESSION_USER

2015-03-18 Thread Robert Haas 
On Tue, Mar 17, 2015 at 1:24 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
 If we ever implement something like

 COMMENT ON CURRENT_DATABASE IS ...

 it will be useful, because you will be able to restore a dump into
 another database and have the comment apply to the target database.
 (Also, I wonder about
 ALTER USER foo IN DATABASE current_database ...
 because that will let us dump per-database user options too.)

+1 for both of those ideas.

-- 
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] Can pg_dump make use of CURRENT/SESSION_USER

2015-03-18 Thread Fabrízio de Royes Mello 
On Wed, Mar 18, 2015 at 1:24 PM, Robert Haas robertmh...@gmail.com wrote:

 On Tue, Mar 17, 2015 at 1:24 PM, Alvaro Herrera
 alvhe...@2ndquadrant.com wrote:
  If we ever implement something like
 
  COMMENT ON CURRENT_DATABASE IS ...
 
  it will be useful, because you will be able to restore a dump into
  another database and have the comment apply to the target database.

I think it's simple to implement, but how about pg_dump... we need to add
new option (like --use-current-database) or am I missing something ?


  (Also, I wonder about
  ALTER USER foo IN DATABASE current_database ...
  because that will let us dump per-database user options too.)

 +1 for both of those ideas.


Can you explain more about this idea?

Regards,

--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
 Timbira: http://www.timbira.com.br
 Blog: http://fabriziomello.github.io
 Linkedin: http://br.linkedin.com/in/fabriziomello
 Twitter: http://twitter.com/fabriziomello
 Github: http://github.com/fabriziomello

Re: [HACKERS] Can pg_dump make use of CURRENT/SESSION_USER

2015-03-18 Thread Fabrízio de Royes Mello 
On Wed, Mar 18, 2015 at 2:42 PM, Fabrízio de Royes Mello 
fabriziome...@gmail.com wrote:



 On Wed, Mar 18, 2015 at 2:24 PM, Robert Haas robertmh...@gmail.com
wrote:
 
  On Wed, Mar 18, 2015 at 1:23 PM, Fabrízio de Royes Mello
  fabriziome...@gmail.com wrote:
If we ever implement something like
   
COMMENT ON CURRENT_DATABASE IS ...
   
it will be useful, because you will be able to restore a dump into
another database and have the comment apply to the target database.
  
   I think it's simple to implement, but how about pg_dump... we need to
add
   new option (like --use-current-database) or am I missing something ?
 
  I think we'd just change it to use the new syntax, full stop.  I see
  no need for an option.
 

 Ok.


(Also, I wonder about
ALTER USER foo IN DATABASE current_database ...
because that will let us dump per-database user options too.)
  
   +1 for both of those ideas.
  
   Can you explain more about this idea?
 
  Uh, what do you want explained?
 

 There's no need, sorry. I just misunderstood it first.

 I'll provide the patches.


Just one last doubt. Do we expose a new function called current_database
like current_catalog, current_user, ... ?

Regards,

--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
 Timbira: http://www.timbira.com.br
 Blog: http://fabriziomello.github.io
 Linkedin: http://br.linkedin.com/in/fabriziomello
 Twitter: http://twitter.com/fabriziomello
 Github: http://github.com/fabriziomello

Re: [HACKERS] Can pg_dump make use of CURRENT/SESSION_USER

2015-03-18 Thread Robert Haas 
On Wed, Mar 18, 2015 at 1:23 PM, Fabrízio de Royes Mello
fabriziome...@gmail.com wrote:
  If we ever implement something like
 
  COMMENT ON CURRENT_DATABASE IS ...
 
  it will be useful, because you will be able to restore a dump into
  another database and have the comment apply to the target database.

 I think it's simple to implement, but how about pg_dump... we need to add
 new option (like --use-current-database) or am I missing something ?

I think we'd just change it to use the new syntax, full stop.  I see
no need for an option.

  (Also, I wonder about
  ALTER USER foo IN DATABASE current_database ...
  because that will let us dump per-database user options too.)

 +1 for both of those ideas.

 Can you explain more about this idea?

Uh, what do you want explained?

-- 
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] Can pg_dump make use of CURRENT/SESSION_USER

2015-03-18 Thread Robert Haas 
On Wed, Mar 18, 2015 at 2:09 PM, Fabrízio de Royes Mello
fabriziome...@gmail.com wrote:
 Just one last doubt. Do we expose a new function called current_database
 like current_catalog, current_user, ... ?

Why would we do that?

-- 
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] Can pg_dump make use of CURRENT/SESSION_USER

2015-03-18 Thread Fabrízio de Royes Mello 
On Wed, Mar 18, 2015 at 3:13 PM, Robert Haas robertmh...@gmail.com wrote:

 On Wed, Mar 18, 2015 at 2:09 PM, Fabrízio de Royes Mello
 fabriziome...@gmail.com wrote:
  Just one last doubt. Do we expose a new function called
current_database
  like current_catalog, current_user, ... ?

 Why would we do that?


We don't need it... it's another patch.

Regards,

--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
 Timbira: http://www.timbira.com.br
 Blog: http://fabriziomello.github.io
 Linkedin: http://br.linkedin.com/in/fabriziomello
 Twitter: http://twitter.com/fabriziomello
 Github: http://github.com/fabriziomello

Re: [HACKERS] Can pg_dump make use of CURRENT/SESSION_USER

2015-03-18 Thread Fabrízio de Royes Mello 
On Wed, Mar 18, 2015 at 3:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:

 =?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= fabriziome...@gmail.com writes:
  Just one last doubt. Do we expose a new function called
current_database
  like current_catalog, current_user, ... ?

 There already is one.  But that would have nothing to do with the proposed
 patch anyway, because the bits of syntax in question are not expressions
 and you should not try to turn them into things that would call functions.


Yeah... I'll focus on the current scope.

Thanks,

--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
 Timbira: http://www.timbira.com.br
 Blog: http://fabriziomello.github.io
 Linkedin: http://br.linkedin.com/in/fabriziomello
 Twitter: http://twitter.com/fabriziomello
 Github: http://github.com/fabriziomello

Re: [HACKERS] Can pg_dump make use of CURRENT/SESSION_USER

2015-03-18 Thread Fabrízio de Royes Mello 
On Wed, Mar 18, 2015 at 2:24 PM, Robert Haas robertmh...@gmail.com wrote:

 On Wed, Mar 18, 2015 at 1:23 PM, Fabrízio de Royes Mello
 fabriziome...@gmail.com wrote:
   If we ever implement something like
  
   COMMENT ON CURRENT_DATABASE IS ...
  
   it will be useful, because you will be able to restore a dump into
   another database and have the comment apply to the target database.
 
  I think it's simple to implement, but how about pg_dump... we need to
add
  new option (like --use-current-database) or am I missing something ?

 I think we'd just change it to use the new syntax, full stop.  I see
 no need for an option.


Ok.


   (Also, I wonder about
   ALTER USER foo IN DATABASE current_database ...
   because that will let us dump per-database user options too.)
 
  +1 for both of those ideas.
 
  Can you explain more about this idea?

 Uh, what do you want explained?


There's no need, sorry. I just misunderstood it first.

I'll provide the patches.

Regards,

--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
 Timbira: http://www.timbira.com.br
 Blog: http://fabriziomello.github.io
 Linkedin: http://br.linkedin.com/in/fabriziomello
 Twitter: http://twitter.com/fabriziomello
 Github: http://github.com/fabriziomello

Re: [HACKERS] Can pg_dump make use of CURRENT/SESSION_USER

2015-03-18 Thread Tom Lane 
=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= fabriziome...@gmail.com writes:
 Just one last doubt. Do we expose a new function called current_database
 like current_catalog, current_user, ... ?

There already is one.  But that would have nothing to do with the proposed
patch anyway, because the bits of syntax in question are not expressions
and you should not try to turn them into things that would call functions.

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] Can pg_dump make use of CURRENT/SESSION_USER

2015-03-17 Thread Bruce Momjian 

Are there any use-cases for pg_dump to use CURRENT/SESSION_USER in its
output, so that restores will not be hard-coded to the dump user?  I
didn't see any cases of that, but wanted to ask.

pg_dump doesn't have to restore into old clusters so there isn't a
problem with backward compatibility.

---

- Forwarded message from Alvaro Herrera alvhe...@alvh.no-ip.org -

Date: Mon, 09 Mar 2015 18:46:02 +
From: Alvaro Herrera alvhe...@alvh.no-ip.org
To: pgsql-committ...@postgresql.org
Subject: [COMMITTERS] pgsql: Allow CURRENT/SESSION_USER to be used in certain 
commands

Allow CURRENT/SESSION_USER to be used in certain commands

Commands such as ALTER USER, ALTER GROUP, ALTER ROLE, GRANT, and the
various ALTER OBJECT / OWNER TO, as well as ad-hoc clauses related to
roles such as the AUTHORIZATION clause of CREATE SCHEMA, the FOR clause
of CREATE USER MAPPING, and the FOR ROLE clause of ALTER DEFAULT
PRIVILEGES can now take the keywords CURRENT_USER and SESSION_USER as
user specifiers in place of an explicit user name.

This commit also fixes some quite ugly handling of special standards-
mandated syntax in CREATE USER MAPPING, which in particular would fail
to work in presence of a role named current_user.

The special role specifiers PUBLIC and NONE also have more consistent
handling now.

Also take the opportunity to add location tracking to user specifiers.

Authors: Kyotaro Horiguchi.  Heavily reworked by Álvaro Herrera.
Reviewed by: Rushabh Lathia, Adam Brightwell, Marti Raudsepp.

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/31eae6028eca4365e7165f5f33fee1ed0486aee0

Modified Files
--
doc/src/sgml/ref/alter_aggregate.sgml|3 +-
doc/src/sgml/ref/alter_collation.sgml|2 +-
doc/src/sgml/ref/alter_conversion.sgml   |2 +-
doc/src/sgml/ref/alter_database.sgml |2 +-
doc/src/sgml/ref/alter_domain.sgml   |2 +-
doc/src/sgml/ref/alter_event_trigger.sgml|2 +-
doc/src/sgml/ref/alter_foreign_data_wrapper.sgml |2 +-
doc/src/sgml/ref/alter_foreign_table.sgml|2 +-
doc/src/sgml/ref/alter_function.sgml |2 +-
doc/src/sgml/ref/alter_group.sgml|   10 +-
doc/src/sgml/ref/alter_language.sgml |2 +-
doc/src/sgml/ref/alter_large_object.sgml |2 +-
doc/src/sgml/ref/alter_materialized_view.sgml|2 +-
doc/src/sgml/ref/alter_opclass.sgml  |   11 +-
doc/src/sgml/ref/alter_operator.sgml |7 +-
doc/src/sgml/ref/alter_opfamily.sgml |   19 +-
doc/src/sgml/ref/alter_role.sgml |   35 +-
doc/src/sgml/ref/alter_schema.sgml   |2 +-
doc/src/sgml/ref/alter_sequence.sgml |2 +-
doc/src/sgml/ref/alter_server.sgml   |2 +-
doc/src/sgml/ref/alter_table.sgml|2 +-
doc/src/sgml/ref/alter_tablespace.sgml   |2 +-
doc/src/sgml/ref/alter_tsconfig.sgml |2 +-
doc/src/sgml/ref/alter_tsdictionary.sgml |2 +-
doc/src/sgml/ref/alter_type.sgml |2 +-
doc/src/sgml/ref/alter_user.sgml |   16 +-
doc/src/sgml/ref/alter_user_mapping.sgml |2 +-
doc/src/sgml/ref/alter_view.sgml |2 +-
doc/src/sgml/ref/create_schema.sgml  |   14 +-
doc/src/sgml/ref/grant.sgml  |   33 +-
src/backend/catalog/aclchk.c |   54 +-
src/backend/commands/alter.c |2 +-
src/backend/commands/extension.c |2 +-
src/backend/commands/foreigncmds.c   |   58 +-
src/backend/commands/policy.c|   18 +-
src/backend/commands/schemacmds.c|   21 +-
src/backend/commands/tablecmds.c |4 +-
src/backend/commands/tablespace.c|2 +-
src/backend/commands/user.c  |  116 +--
src/backend/nodes/copyfuncs.c|   49 +-
src/backend/nodes/equalfuncs.c   |   45 +-
src/backend/parser/gram.y|  228 --
src/backend/parser/parse_utilcmd.c   |4 +-
src/backend/utils/adt/acl.c  |  116 ++-
src/include/commands/user.h  |2 +-
src/include/nodes/nodes.h|1 +
src/include/nodes/parsenodes.h   |   50 +-
src/include/utils/acl.h  |8 +-
src/test/regress/expected/rolenames.out  |  940 ++
src/test/regress/parallel_schedule   |2 +-
src/test/regress/serial_schedule |1 +
src/test/regress/sql/rolenames.sql   |  434 ++
52 files changed, 2000 insertions(+), 347 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committ...@postgresql.org)
To make changes to your

Re: [HACKERS] Can pg_dump make use of CURRENT/SESSION_USER

2015-03-17 Thread Alvaro Herrera 
Bruce Momjian wrote:
 
 Are there any use-cases for pg_dump to use CURRENT/SESSION_USER in its
 output, so that restores will not be hard-coded to the dump user?  I
 didn't see any cases of that, but wanted to ask.

Good question.  I don't know, probably not.

If we ever implement something like

COMMENT ON CURRENT_DATABASE IS ...

it will be useful, because you will be able to restore a dump into
another database and have the comment apply to the target database.
(Also, I wonder about
ALTER USER foo IN DATABASE current_database ...
because that will let us dump per-database user options too.)


-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training  Services


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