Kyotaro HORIGUCHI wrote: > Thank you for completing this and very sorry not to respond these > days. > > I understood that it is committed after I noticed that rebasing > my code failed..
You'd do well to check your email, I guess :-) > Although after committed, I found some issues as I looked on > it. Please forgive me to comment it now after all this time. > ==== > | =# alter role current_user rename to "PubLic"; > | ERROR: CURRENT_USER cannot be used as a role name > | LINE 1: alter role current_user rename to "PubLic"; > | ^ > > The error message sounds somewhat different from the intention. I > think the following message would be clearer. > > | ERROR: CURRENT_USER cannot be used as a role name here Okay, changed. > ==== > The document sql-altergroup.html says > > | ALTER GROUP role_specification ADD USER user_name [, ... ] > > But current_user is also usable in user_name list. So the doc > should be as following, but it would not be necessary to be fixed > because it is an obsolete commnand.. > > | ALTER GROUP role_specification ADD USER role_specification [, ... ] Yeah, EDONTCARE. > "ALTER GROUP role_spec ADD/DROP USER role_spec" is naturally > denied so I think no additional description is needed. +1 > ==== > sql-alterpolicy.html > > "ALTER POLICY name ON table_name TO" also accepts current_user > and so as the role to which the policy applies. Changed. > # As a different topic, the syntax "ALTER POLICY <pname> ON > # <tname> TO <user>" looks a bit wired, it might be better be to > # be "ON <tname> APPLY TO <user>" but I shouldn't try to fix it > # since it is a long standing syntax.. Yeah, it's a bit strange. Not a strong opinion. Maybe you should raise it as a separate thread. > ==== > sql-createtablespace.html > sql-drop-owned.html, sql-reassign-owned.html Changed. > ====== > sql-grant.html, sql-revoke.html, > > "GRANT <roles> TO <roles>" and "REVOKE <roles> FROM <roles>" are > the modern equivalents of the deprecated syntaxes "ALTER <roles> > ADD USER <roles>" and "ALTER <roles> DROP USER <roles>" > respectively. But the current parser infrastructure doesn't allow > coexistence of the two following syntaxes but I couldn't find the > way to their coexistence. I decided to leave this out. I think we should consider it as a new patch for 9.6; these changes aren't as clear-cut as the rest of your patch. I didn't want to have to research the ecpg changes. -- Álvaro Herrera http://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