Re: Re: [PATCHES] Fw: Isn't pg_statistic a security hole - Solution Proposal - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Re: [PATCHES] Fw: Isn't pg_statistic a security hole - Solution Proposal
Date
Msg-id Pine.LNX.4.30.0106071607580.757-100000@peter.localdomain
Whole thread Raw
In response to Re: Re: [PATCHES] Fw: Isn't pg_statistic a security hole - Solution Proposal  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Re: [PATCHES] Fw: Isn't pg_statistic a security hole - Solution Proposal  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane writes:

> My feeling is that the name-based variants of has_table_privilege should
> perform downcasing and truncation of the supplied strings before trying
> to use them as tablename or username; see get_seq_name in
> backend/commands/sequence.c for a model.

I don't like this approach.  It's ugly, non-intuitive, and inconvenient.

Since these functions will primarily be used in building a sort of
information schema and for querying system catalogs, we should use the
approach that is or will be used there:  character type values contain the
table name already case-adjusted.  Imagine the pain we would have to go
through to *re-quote* the names we get from the system catalogs and
information schema components before passing them to this function.

-- 
Peter Eisentraut   peter_e@gmx.net   http://funkturm.homeip.net/~peter



pgsql-hackers by date:

Previous
From: Thomas Lockhart
Date:
Subject: Re: [SQL] behavior of ' = NULL' vs. MySQL vs. Standards
Next
From: Vince Vielhaber
Date:
Subject: grant and SQL92