Re: [HACKERS] Support for JDBC setQueryTimeout, et al.
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Support for JDBC setQueryTimeout, et al. |
Дата | |
Msg-id | 16569.1287177976@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Support for JDBC setQueryTimeout, et al. (Stephen Frost <sfrost@snowman.net>) |
Список | pgsql-jdbc |
Stephen Frost <sfrost@snowman.net> writes: > IOW, yeah, you're right, the role doesn't really matter. One thing that > occurs to me when I last ran into a problem with this- it was painful to > debug because the "permission denied" error didn't indicate which schema > the table it was trying to access was in. I wonder if we could fix > that. Hm, are you sure you actually got a "permission denied" error? Because AFAICS such a message would name the schema: regression=> select * from s1.t1; ERROR: permission denied for schema s1 The part that is a bit nasty is if you try to put a schema in your search_path that you don't have permissions for. My recollection is that we just silently drop it out of the effective search path, so: regression=> set search_path = s1, public; SET regression=> select current_schemas(false); current_schemas ----------------- {public} (1 row) regression=> select * from t1; ERROR: relation "t1" does not exist This isn't terribly user-friendly, but I'm not sure how to do better. We can't really throw an error at the point of setting the search path, because there are too many scenarios where a default search path is effectively set up for you, and it might or might not list some unsearchable (or even nonexistent) schemas. regards, tom lane
В списке pgsql-jdbc по дате отправления: