Various bugs/issues
От | Alexander Borkowski |
---|---|
Тема | Various bugs/issues |
Дата | |
Msg-id | 4187221B.7060002@abri.une.edu.au обсуждение исходный текст |
Ответы |
Re: Various bugs/issues
|
Список | 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
В списке pgadmin-hackers по дате отправления: