Обсуждение: Bug: SQL pane: schema-prefix of composite types duplicated

Hi developers!

I am testing pgAdmin III Beta 3 (Oct 12 2006, re: 5475) on Windows
XP (German, latest patch level).

Concerns functions that RETURN composite types. If the type is defined 
in a schema other than public (or first in search_path?), then pgAdmin 
gets it wrong.
This is the case with implicitely created composite types (return type 
of views) as well as with explicitely created types:
CREATE TYPE myschema.t_mytype AS
(...)

Looking up the definition of a function in the SQL pane, I get:
CREATE OR REPLACE FUNCTION export.f_test(integer) RETURNS SETOF myschema."myschema.v_myview" AS      -- NOTE: 
schema-name duplicated
(...)

Should read:
CREATE OR REPLACE FUNCTION export.f_test(integer) RETURNS SETOF myschema.v_myview AS
(...)

Of course, if I try to execute that SQL script I get an error:
FEHLER: Typ myschema.myschema.v_myview« existiert nicht
SQL state: 42704

I think this one has been introduced with Beta 3.


I plan on further reports (provided I find more bugs). If you would like 
me to report in any other fashion, please let me know. I am trying to be 
helpful.


Regards
Erwin Brandstetter

Thanks, I've committed a patch to SVN that should solve this.

Regards, Dave

> -----Original Message-----
> From: pgadmin-support-owner@postgresql.org
> [mailto:pgadmin-support-owner@postgresql.org] On Behalf Of
> Erwin Brandstetter
> Sent: 15 October 2006 23:54
> To: pgadmin-support@postgresql.org
> Subject: [pgadmin-support] Bug: SQL pane: schema-prefix of
> composite types duplicated
>
> Hi developers!
>
> I am testing pgAdmin III Beta 3 (Oct 12 2006, re: 5475) on Windows
> XP (German, latest patch level).
>
> Concerns functions that RETURN composite types. If the type
> is defined
> in a schema other than public (or first in search_path?),
> then pgAdmin
> gets it wrong.
> This is the case with implicitely created composite types
> (return type
> of views) as well as with explicitely created types:
> CREATE TYPE myschema.t_mytype AS
> (...)
>
> Looking up the definition of a function in the SQL pane, I get:
> CREATE OR REPLACE FUNCTION export.f_test(integer)
>   RETURNS SETOF myschema."myschema.v_myview" AS      -- NOTE:
> schema-name duplicated
> (...)
>
> Should read:
> CREATE OR REPLACE FUNCTION export.f_test(integer)
>   RETURNS SETOF myschema.v_myview AS
> (...)
>
> Of course, if I try to execute that SQL script I get an error:
> FEHLER: Typ myschema.myschema.v_myview< existiert nicht
> SQL state: 42704
>
> I think this one has been introduced with Beta 3.
>
>
> I plan on further reports (provided I find more bugs). If you
> would like
> me to report in any other fashion, please let me know. I am
> trying to be
> helpful.
>
>
> Regards
> Erwin Brandstetter
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
>                http://archives.postgresql.org
>

Hi Dave!

I am afraid I have encountered another one of those undead bugs.
It would seem that the case where the return type of a function is 
specified via OUT-parameter has slipped through:
That's what I get for one of my real functions (note the duplicated 
schema-name with the OUT-parameter!):

CREATE OR REPLACE FUNCTION cp.f_todo_interesse(OUT t cp."cp.t_todo") RETURNS SETOF cp.t_todo AS
$BODY$
(...)


Regards
Erwin

Erwin Brandstetter wrote:
> Hi Dave!
> 
> I am afraid I have encountered another one of those undead bugs.
> It would seem that the case where the return type of a function is 
> specified via OUT-parameter has slipped through:
> That's what I get for one of my real functions (note the duplicated 
> schema-name with the OUT-parameter!):
> 
> CREATE OR REPLACE FUNCTION cp.f_todo_interesse(OUT t cp."cp.t_todo")
>  RETURNS SETOF cp.t_todo AS
> $BODY$
> (...)

Blergh!! I've gone over the code and ripped out a bunch of stuff that 
used to be there to manually quote things. Now it's gone, there's no way 
anything in that area could end up being double quoted without raising a  compiler error.

As always, thanks for the report - I'll probably cut an RC2 build tomorrow.

Regards, Dave