Thread: 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