Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

meta: meta.relation_column has false primary keys for all columns when user is read-only #233

Open
erichanson opened this issue Jan 7, 2021 · 0 comments

Comments

@erichanson
Copy link
Member

select * from meta.relation_column where primary_key = 't';

is always empty. Which means meta.untracked_rows is always empty.

Tracked this down to information_schema.table_constraints, which is empty because

has_table_privilege(r.oid, 'INSERT, UPDATE, DELETE, TRUNCATE, REFERENCES, TRIGGER'::text)

by default doesn't include SELECT. Adding SELECT (in two places) makes it so it at least returns results.

Problem code is here, where they note it as seemingly an anomaly.

IRC says:

 erichanson | I'm trying to create a read-only user, but that user is unable to see primary     
            | keys via information_schema.table_constraints.  tracked down the reason here:     
            | shorturl.at/fjET0 .  SQL Standard requires the user has_table_privilege() of      
            | something *other than* select.  Anybody know the rationale behind this?           
 erichanson | I can just dig it out of pg_catalog but it's not going to be pretty and is a lot  
            | more fragile to version changes etc.                                              
 erichanson | They even note it in the comments, as if it were an oddity, which it seems to be  
RhodiumToad | the thinking (as far as I can tell) behind the access restrictions in             
            | information_schema is that you're supposed to be able to see stuff that might     
            | affect you, and not otherwise                                                     
 erichanson | Ah.  As in if I can't insert, there's no point in knowing about constraints       
RhodiumToad | so you don't see constraints unless you have permissions that you might violate   
            | them with                                                                         
RhodiumToad | or something.                                                                     
 erichanson | Gotcha.  Well, disagree, but thanks for the explaination :)                       
          * | RhodiumToad has a fairly low opinion of the spec                                  
 erichanson | ^^                                                                                

Going to have to work around this somehow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant