Thread: Various bugs/issues
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
Alexander Borkowski wrote: > 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 Fixed. > 2. Changing the name of an operator does not work either. The error > message is It's 8.0 only, disabled for older versions now. > 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. Extracted [] from quoting. Hopefully, nobody will use type names that include trailing []... Type handling really needs a major rewrite, but it's so boring... > 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. This pre-8.0 alter column feature is a delicate thing... Fixed now. > 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? This is subject to discussion. For most users, probably it's correct to restrict composite types to have >1 member; less doesn't make too much sense (I'd suggest a domain instead). Not everything that's legal is also sensible, so I'd opt to leave this a little restricted to reduce newbie's surprises. Committed to CVS, Thanks for your precise bug report! New win32 snapshot uploading soon. Regards, Andreas
Alexander Borkowski wrote: > >> Type handling really needs a major rewrite, but it's so boring... > Can you roughly outline what would be involved in doing this? There's already some stuff in pgDatatype, but the class was invented too late when I realized that typehandling is more complicated than it appeared initially. Every string/parameter formatting/encoding should be concentrated there. This involves some rewrite of type usage in schema and ui files as well. >>> 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? >> >> >> This is subject to discussion. For most users, probably it's correct >> to restrict composite types to have >1 member; less doesn't make too >> much sense (I'd suggest a domain instead). Not everything that's legal is >> also sensible, so I'd opt to leave this a little restricted to reduce >> newbie's surprises. > > > Is do see your point. May I nevertheless suggest a warning dialog > instead? Something along the lines of: "You are trying to create a > composite type with only one member. We're planning a guru hint mechanism for 1.3/1.4, so this is certainly a candidate. Regards, Andreas
Andreas Pflug wrote: >>> Type handling really needs a major rewrite ... > There's already some stuff in pgDatatype, but the class was invented too > late when I realized that typehandling is more complicated than it > appeared initially. Every string/parameter formatting/encoding should be > concentrated there. This involves some rewrite of type usage in schema > and ui files as well. Ok, I think I got the idea. Looks pretty interesting really, I will take a closer look at that during the weekend and see if I could handle it. The GUI part may be the problem for me there, as I have done mostly server-side stuff so far. In the meantime, I found another bug in dlgCast (1.2.0 post-beta3, WinXP). I have only one candiate as cast function in my case but the list contains an empty string and the function name - four times, and only the first occurrence of the function name in this list leads to a sensible result in the SQL tab. This appears to be caused by not clearing cbFunctions when necessary, and I was able to fix this by adding cbFunctions->Clear(); to the top of dlgCast::OnChangeType(wxCommandEvent&), but I am not sure whether this is actually the right thing to do. Also, when selecting 'New Cast' from the Casts context menu in the debug build version only, instead of the new cast dialog an error dialog with a message about an unhandled exception comes up (choices Abort, Retry, and Ignore). It still does after my change. > We're planning a guru hint mechanism for 1.3/1.4, so this is certainly a > candidate. That's excellent! Regards, Alex
Alexander Borkowski wrote: > Andreas Pflug wrote: > >>>> Type handling really needs a major rewrite > > ... > >> There's already some stuff in pgDatatype, but the class was invented >> too late when I realized that typehandling is more complicated than it >> appeared initially. Every string/parameter formatting/encoding should >> be concentrated there. This involves some rewrite of type usage in >> schema and ui files as well. > > > Ok, I think I got the idea. Looks pretty interesting really, I will take > a closer look at that during the weekend and see if I could handle it. > The GUI part may be the problem for me there, as I have done mostly > server-side stuff so far. Since this is a little fragile, we won't do more than hotfixing on that in 1.2. > > In the meantime, I found another bug in dlgCast (1.2.0 post-beta3, > WinXP). I have only one candiate as cast function in my case but the > list contains an empty string and the function name - four times, and > only the first occurrence of the function name in this list leads to a > sensible result in the SQL tab. This appears to be caused by not > clearing cbFunctions when necessary, and I was able to fix this by adding > > cbFunctions->Clear(); Yup, this is the correct fix; applied to CVS. > > Also, when selecting > 'New Cast' from the Casts context menu in the debug build version only, > instead of the new cast dialog an error dialog with a message about an > unhandled exception comes up (choices Abort, Retry, and Ignore). It > still does after my change. Hm, I don't see this here. Do you have a stack trace? Regards, Andreas