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

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