* Adam Brightwell (adam.brightw...@crunchydatasolutions.com) wrote:
> > +RoleId: CURRENT_USER { $$ =
> > "current_user";}
> > + | USER { $$ = "current_user";}
> > + | CURRENT_ROLE { $$ = "current_user";}
> > + | SESSION_USER { $$ = "session_user";}
> >
> > This is kind of ugly, and it means you can't distinguish between a
> > CURRENT_USER keyword and a quoted user name "current_user".
>
> You are right. I'm not sure I have an opinion on how clean it is, but
> FWIW, it is similar to the way that the 'auth_ident' type in the grammar is
> defined (though, not to imply that it makes it right).
No, it's not right and it's an existing problem. :(
=*# create extension postgres_fdw;
CREATE EXTENSION
=# create server s1 foreign data wrapper postgres_fdw ;
CREATE SERVER
=*# create user mapping for "current_user" server s1;
CREATE USER MAPPING
=*# table pg_user_mappings;
-[ RECORD 1 ]-----
umid | 24623
srvid | 24622
srvname | s1
umuser | 16384
usename | sfrost
umoptions |
> As well, the
> originally proposed "RoleId_or_curruser" suffers from the same issue. I'm
> going to go out on a limb here, but is it not possible to consider
> "current_user", etc. reserved in the same sense that we do with PUBLIC and
> NONE and disallow users/roles from being created as them?
Maybe we could in some future release, but we can't for back-branches so
I'm afraid we're going to have to figure out how to fix this to work
regardless.
> I mean, after
> all, they *are* already reserved keywords. Perhaps there is a very good
> reason why we wouldn't want to do that and I am sure there is since they
> have not been treated this way thus far. If anyone would like to share
> why, then I'd very much appreciate the "lesson".
You can still double-quote reserved words and use them in general. What
we're talking about here are cases where a word can't be used even if
it's double-quoted, and we try really hard to keep those cases at an
absolute minimum. We should also really be keeping a list of those
cases somewhere, now that I think about it..
> Taking a step back, I'm still not sure I understand the need for this
> feature or the use case. It seems to have started as a potential fix to an
> inconsistency between ALTER USER and ALTER ROLE syntax (which I think I
> could see some value in). However, I think it has been taken beyond just
> resolving the inconsistency and started to cross over into feature creep.
> Is the intent simply to resolve inconsistencies between what is now an
> alias of another command? Or is it to add new functionality? I think the
> original proposal needs to be revisited and more time needs to be spent
> defining the scope and purpose of this patch.
I agree that we should probably seperate the concerns here. Personally,
I like the idea of being able to say "CURRENT_USER" in utility commands
to refer to the current user where a role would normally be expected, as
I could see it simplifying things for some applications, but that's a
new feature and independent of making role-vs-user cases more
consistent.
Thanks!
Stephen
signature.asc
Description: Digital signature
