Re: Re: [PATCHES] Fw: Isn't pg_statistic a security hole - Solution Proposal
От | Tom Lane |
---|---|
Тема | Re: Re: [PATCHES] Fw: Isn't pg_statistic a security hole - Solution Proposal |
Дата | |
Msg-id | 27207.992452921@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Re: [PATCHES] Fw: Isn't pg_statistic a security hole - Solution Proposal (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: Re: [PATCHES] Fw: Isn't pg_statistic a security hole
- Solution Proposal
|
Список | pgsql-hackers |
Peter Eisentraut <peter_e@gmx.net> writes: >> Could we make the assumption that table names in catalogs >> will be of type 'name'? > I wouldn't want to guarantee it for the information schema. Your objections are not without merit, and in the interest of bringing this thing to closure I'll concede for now. I want to get on with this so that I can wrap up the pg_statistic view that started the whole thread. What I suggest we do is apply the portions of Joe's latest patch that support has_table_privilege with OID inputs and with NAME inputs, omitting the combinations that take TEXT inputs and do casefolding. We can add that part later if it proves that people do indeed want it. I have specific reasons for wanting to keep the functions accepting NAME rather than TEXT: that will save a run-time type conversion in the common case where one is reading the input from a system catalog, and it will at least provide automatic truncation of overlength names when one is accepting a literal. (I trust Peter won't object to that ;-).) We will probably have to revisit this territory when we implement schemas: there will need to be a way to input qualified table names like foo.bar, and a way to input NON qualified names like "foo.bar". But we can cross that bridge when we come to it. Comments, objections? regards, tom lane
В списке pgsql-hackers по дате отправления: