On Tue, Mar 20, 2012 at 2:07 PM, Dave Page <[email protected]> wrote:
> On Tue, Mar 20, 2012 at 7:35 AM, Ashesh Vashi > <[email protected]> wrote: > > Reason for the error: > > > > REL-9_1_STABLE branch (PostgreSQL repository): > > > > commit 303696c3b47e6719e983e93da5896ddc4a2e0dbb > > Author: Tom Lane <[email protected]> > > Date: Fri Sep 3 01:34:55 2010 +0000 > > > > Install a data-type-based solution for protecting pg_get_expr(). > > > > Since the code underlying pg_get_expr() is not secure against > malformed > > input, and can't practically be made so, we need to prevent > miscreants > > from feeding arbitrary data to it. We can do this securely by > declaring > > pg_get_expr() to take a new datatype "pg_node_tree" and declaring the > > system catalog columns that hold nodeToString output to be of that > type. > > There is no way at SQL level to create a non-null value of type > > pg_node_tree. > > Since the backend-internal operations that fill those catalog columns > > operate below the SQL level, they are oblivious to the datatype > > relabeling > > and don't need any changes. > > Oh yeah, I vaguely remember that. Surely that wasn't back ported to > 9.0 though? Akshay said he sees the issue there as well (which I > don't). > Certainly not in PostgreSQL 9.0. I can't find those changes in PPAS. -- Thanks & Regards, Ashesh Vashi EnterpriseDB INDIA: Enterprise PostgreSQL Company<http://www.enterprisedb.com/> *http://www.linkedin.com/in/asheshvashi* > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
