Skip site navigation (1) Skip section navigation (2)

Re: Fixed issue "Error Message is displayed when the Package is Clicked"

From: Dave Page <dpage(at)pgadmin(dot)org>
To: Akshay Joshi <akshay(dot)joshi(at)enterprisedb(dot)com>
Cc: Ashesh Vashi <ashesh(dot)vashi(at)enterprisedb(dot)com>, pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org>
Subject: Re: Fixed issue "Error Message is displayed when the Package is Clicked"
Date: 2012-03-20 09:32:12
Message-ID: CA+OCxoz9xT8m6ZKpcvSFVCyc1_t_N=_XCeG913OCDe9cC2_Pvg@mail.gmail.com (view raw or flat)
Thread:
Lists: pgadmin-hackers
On Tue, Mar 20, 2012 at 9:27 AM, Akshay Joshi <akshay(dot)joshi(at)enterprisedb(dot)com
> wrote:

>
>
> On Tue, Mar 20, 2012 at 2:17 PM, Ashesh Vashi <
> ashesh(dot)vashi(at)enterprisedb(dot)com> wrote:
>
>> On Tue, Mar 20, 2012 at 2:07 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>
>>> On Tue, Mar 20, 2012 at 7:35 AM, Ashesh Vashi
>>> <ashesh(dot)vashi(at)enterprisedb(dot)com> wrote:
>>> > Reason for the error:
>>> >
>>> > REL-9_1_STABLE branch (PostgreSQL repository):
>>> >
>>> > commit 303696c3b47e6719e983e93da5896ddc4a2e0dbb
>>> > Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
>>> > 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.
>>
>
>   Sorry my mistake, When I run pgadmin3 PPAS9.0 is down and 9.1 is running
> on port 5444. When I add the server by mistake give port to 5444 which is
> of PPAS 9.1. So bug is not reproducible on PPAS 9.0
>
>
OK, so the next step is to figure out where that query is created in the
source, and figure out how to fix it for 9.1. I assume/hope we can just
cast the string to the new type.


-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

pgadmin-hackers by date

Next:From: Guillaume LelargeDate: 2012-03-20 21:00:34
Subject: pgAdmin III commit: Drop autovacuum ANALYZE parameters for TOASTtables
Previous:From: Akshay JoshiDate: 2012-03-20 09:27:26
Subject: Re: Fixed issue "Error Message is displayed when the Package is Clicked"

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group