Обсуждение: Fixed issue "Error Message is displayed when the Package is Clicked"

Hi

On Thu, Mar 15, 2012 at 2:59 PM, Akshay Joshi
<akshay.joshi@enterprisedb.com> wrote:
> Hi Dave
>
> I have fixed one issue "Error Message is displayed when the Package is
> Clicked". I have performed the following on enterprisedb database
>
> create or replace package pkgFoo is
>         procedure foo(
>                 arg1 IN varchar default 'Nothing',
>                 arg2 IN integer default 100
>         );
> end pkgFoo;
>
> create or replace package body pkgFoo is
>         procedure foo(
>                 arg1 IN varchar default 'Nothing',
>                 arg2 IN integer default 100
>         ) is
>         begin
>                 dbms_output.put_line(arg1);
>                 dbms_output.put_line(arg2);
>         end;
> end pkgFoo;
>
> Now click on pkgFoo, we will get the error message.It only happens the first
> time.

I cannot reproduce the error, using GIT Master with PPAS 9.0 on CentOS 5.

> Attached is the patch file, please review it. If it looks good then please
> commit it.

The patch is wrong. The restriction is supposed to be " = 'void'" for
procedures, and " != 'void'" for functions, as it already is.

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

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

On Mon, Mar 19, 2012 at 2:35 PM, Akshay Joshi

<akshay.joshi@enterprisedb.com> wrote:
> Hi
>
> On Mon, Mar 19, 2012 at 7:29 PM, Dave Page <dpage@pgadmin.org> wrote:
>>
>> Hi
>>
>> On Thu, Mar 15, 2012 at 2:59 PM, Akshay Joshi
>> <akshay.joshi@enterprisedb.com> wrote:
>> > Hi Dave
>> >
>> > I have fixed one issue "Error Message is displayed when the Package is
>> > Clicked". I have performed the following on enterprisedb database
>> >
>> > create or replace package pkgFoo is
>> >         procedure foo(
>> >                 arg1 IN varchar default 'Nothing',
>> >                 arg2 IN integer default 100
>> >         );
>> > end pkgFoo;
>> >
>> > create or replace package body pkgFoo is
>> >         procedure foo(
>> >                 arg1 IN varchar default 'Nothing',
>> >                 arg2 IN integer default 100
>> >         ) is
>> >         begin
>> >                 dbms_output.put_line(arg1);
>> >                 dbms_output.put_line(arg2);
>> >         end;
>> > end pkgFoo;
>> >
>> > Now click on pkgFoo, we will get the error message.It only happens the
>> > first
>> > time.
>>
>> I cannot reproduce the error, using GIT Master with PPAS 9.0 on CentOS 5.
>
>
>   I am able to reproduce this every first time after launching pgAdmin using
> GIT Master with PPAS9.1 on Windows 7. Attached is the screen shot.
>>
>>
>> > Attached is the patch file, please review it. If it looks good then
>> > please
>> > commit it.
>>
>> The patch is wrong. The restriction is supposed to be " = 'void'" for
>> procedures, and " != 'void'" for functions, as it already is.
>
>
>   OK. I am not much aware of that code, but we have to provide some other
> fix for the mentioned issue.

Hmm, that looks like something changed in 9.1 that needs handling
differently. Can you work out exactly what the query that causes the
error is? We may need to check with one of the server guys.

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

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

On Tue, Mar 20, 2012 at 7:35 AM, Ashesh Vashi
<ashesh.vashi@enterprisedb.com> wrote:
> Reason for the error:
>
> REL-9_1_STABLE branch (PostgreSQL repository):
>
> commit 303696c3b47e6719e983e93da5896ddc4a2e0dbb
> Author: Tom Lane <tgl@sss.pgh.pa.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).

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

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

On Tue, Mar 20, 2012 at 2:07 PM, Dave Page <dpage@pgadmin.org> wrote:

On Tue, Mar 20, 2012 at 7:35 AM, Ashesh Vashi
<ashesh.vashi@enterprisedb.com> wrote:
> Reason for the error:
>
> REL-9_1_STABLE branch (PostgreSQL repository):
>
> commit 303696c3b47e6719e983e93da5896ddc4a2e0dbb
> Author: Tom Lane <tgl@sss.pgh.pa.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.

--

Thanks & Regards,

Ashesh Vashi
EnterpriseDB INDIA: Enterprise PostgreSQL Company

 

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

On Tue, Mar 20, 2012 at 2:17 PM, Ashesh Vashi <ashesh.vashi@enterprisedb.com> wrote:

On Tue, Mar 20, 2012 at 2:07 PM, Dave Page <dpage@pgadmin.org> wrote:

On Tue, Mar 20, 2012 at 7:35 AM, Ashesh Vashi
<ashesh.vashi@enterprisedb.com> wrote:
> Reason for the error:
>
> REL-9_1_STABLE branch (PostgreSQL repository):
>
> commit 303696c3b47e6719e983e93da5896ddc4a2e0dbb
> Author: Tom Lane <tgl@sss.pgh.pa.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