Re: Re: [PATCHES] Fw: Isn't pg_statistic a security hole - Solution Proposal
От | Peter Eisentraut |
---|---|
Тема | Re: Re: [PATCHES] Fw: Isn't pg_statistic a security hole - Solution Proposal |
Дата | |
Msg-id | Pine.LNX.4.30.0106091203180.778-100000@peter.localdomain обсуждение исходный текст |
Ответ на | Re: Re: [PATCHES] Fw: Isn't pg_statistic a security hole - Solution Proposal (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Re: [PATCHES] Fw: Isn't pg_statistic a security hole -
Solution Proposal
Re: Re: [PATCHES] Fw: Isn't pg_statistic a security hole - Solution Proposal |
Список | pgsql-hackers |
Tom Lane 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. > If so, it'd work to make two versions of the has_table_privilege > function, one taking type "name" and the other taking type "text". > The "name" version would take its input as-is, the "text" version > would do case folding and truncation. Target typing is ugly. I've tried to look up the supposed \paraphrase{we had enough problems before we added the existing behaviour to setval, etc.} discussion but couldn't find it. My experience on the mailing list is that it goes the other way. The identifier quoting rules are already surprising enough for the uninitiated, but it's even more surprising that they even apply when syntactically no identifier is present. Between the behaviour of "what you see is what you get" and "this language is kind of confusing so you have to quote your strings twice with two different quoting characters" the choice is obvious to me. I'm also arguing for consistency with the standard. According to that, users will be able to do SELECT * FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = 'SoMeThInG'; and a load of similar queries. You can't change the case folding rules here unless you really want to go out of your way, and then you have really confused the heck out of users. We could make relname.func() work without breaking compatibility, ISTM, and then we only need the Oid version. For computing the relation name at execution time, the "plain" version is going to be more useful anyway. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
В списке pgsql-hackers по дате отправления: