Various bugs/issues

From: Alexander Borkowski <alexander(dot)borkowski(at)abri(dot)une(dot)edu(dot)au>
To: pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org>
Subject: Various bugs/issues
Date: 2004-11-02 05:58:51
Message-ID: 4187221B.7060002@abri.une.edu.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-hackers

Dear all,

I got around to to some more work with pgAdmin III today after a little
break and upgraded to 1.2.0 post-beta3 (WinXP, PostgreSQL 7.4.3
backend). During my work I encountered several issues which I would like
to report:

1. Changing the owner of a table, view, or domain, which is not in the
"public" schema does not work as the generated "ALTER ... OWNER TO ..."
statement lacks the schema qualification for the object whose owner is
to be changed. Instead the error message

ERROR: relation "..." does not exist

comes up (where ... is the name of the table or view). There is a
similar error for domains. BTW, the generated SQL statement reads "ALTER
Table ..." for tables and "ALTER Domain ..." for domains (instead of
"ALTER TABLE ..." or "ALTER DOMAIN ..."). I know the latter is not
critical, but maybe it helps to figure out what is going wrong.

2. Changing the name of an operator does not work either. The error
message is

ERROR: syntax error at or near "+|+" at character 16.

for the statement

ALTER OPERATOR +|+(text, text) OWNER TO agb;

As the documentation for PostgreSQL 7.4.3 does not mention an "ALTER
OPERATOR" statement, this capability should probably be disabled for the
respective backend version.

3. I tried to create a pl/pgsql function which accepts a text[]
argument. The dialog raises the following error message if I try to
create such a function:

ERROR: type text[] does not exist.

I then copied the contents of the SQL tab (i.e. the function definition)
to a query window, change the "text[]" to "text"[] and execute it
everything is fine. After this had happend I also tried to create
functions with other array types (int4[] and oid[]) as arguments and got
the same error (apart from the type name of course).

4. Earlier I changed the type of one of my columns in one of my tables
from varchar(64) to text. Unfortunately, during my first attempt I
selected the new type "text" in the column property dialog before
deleting the contents of the Length field, so the column type was
changed to text(64) instead of text, which apparently works fine in
queries. This is probably due to the fact that PostgreSQL stores these
types in the same binary format anyway. The problem is that the table
definition (with the text(64) column) saved as file and used to recreate
the table fails with a syntax error, so I would classifiy this as bug.

5. Creating a composite type requires at least two member fields to be
added (the OK button stays disabled until there are at least two members
defined). According to line 240 of src/ui/dlgType.cpp this is
intentional, but at least according to my PostgreSQL documentation it is
valid to have a composite type with just one field. IMHO this does make
sense, as one can create a table with only one column as well. Am I
missing something?

Cheers,

Alex

Responses

Browse pgadmin-hackers by date

  From Date Subject
Next Message cvs 2004-11-02 16:12:08 CVS Commit by andreas: Fix some type related issues Fix some owner
Previous Message cvs 2004-11-01 20:52:25 CVS Commit by dpage: Look for a path 'hint' on Windows.