Обсуждение: bug in pgadmin 1.8.2: missing entry in 'Data Type' list
Prerequisites: Binary downloaded from website, used along with Postgres 8.3.0 Windows XP Pro, SP2 Steps to reproduce 1) create a simple table with two columns : create test_table(a integer, b integer); 2) go to ‘New Table..” menu, type in some table name, 3) go to ‘Columns’ tab, type some column name, ‘a’ for instance and try to find type ‘test_table’ in the drop-down ‘DataType’ list. You should see only test_table[], not test_table which doesn’t seem correct. Regards, Peter G.
On Feb 12, 2008 9:12 PM, Peter Gagarinov <heartofmars@gmail.com> wrote: > > 1) create a simple table with two columns : > > create test_table(a integer, b integer); > > 2) go to 'New Table.." menu, type in some table name, > > 3) go to 'Columns' tab, type some column name, 'a' for instance and try to find type 'test_table' in the drop-down'Data Type' list. > > You should see only test_table[], not test_table which doesn't seem correct. I *think* the original intent was to not show table types at all, which probably got broken when array types were re-jigged for 8.3 - however, I don't see why we wouldn't want to see them as they are perfectly valid to use. The attached patch fixes this for me - can I get one or two of the other hackers to test this and confirm that a) I got the logic right in the change to the query and b) there is no good reason not to show the table types (Magnus, Guillaume :-))? Cheers, Dave -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com The Oracle-compatible database company
Вложения
Dave Page wrote: > On Feb 12, 2008 9:12 PM, Peter Gagarinov <heartofmars@gmail.com> wrote: >> 1) create a simple table with two columns : >> >> create test_table(a integer, b integer); >> >> 2) go to 'New Table.." menu, type in some table name, >> >> 3) go to 'Columns' tab, type some column name, 'a' for instance and try to find type 'test_table' in the drop-down'Data Type' list. >> >> You should see only test_table[], not test_table which doesn't seem correct. > > I *think* the original intent was to not show table types at all, > which probably got broken when array types were re-jigged for 8.3 - > however, I don't see why we wouldn't want to see them as they are > perfectly valid to use. There is a good reason not to show them by default - that list is long enough already, and weird enough for new users. Adding every single table you have makes it even more complex. So perhaps adding it, but not by default, enabled by a checkbox? //Magnus
Magnus Hagander a écrit : > Dave Page wrote: >> On Feb 12, 2008 9:12 PM, Peter Gagarinov <heartofmars@gmail.com> wrote: >>> 1) create a simple table with two columns : >>> >>> create test_table(a integer, b integer); >>> >>> 2) go to 'New Table.." menu, type in some table name, >>> >>> 3) go to 'Columns' tab, type some column name, 'a' for instance >>> and try to find type 'test_table' in the drop-down 'Data Type' list. >>> >>> You should see only test_table[], not test_table which doesn't seem >>> correct. >> >> I *think* the original intent was to not show table types at all, >> which probably got broken when array types were re-jigged for 8.3 - >> however, I don't see why we wouldn't want to see them as they are >> perfectly valid to use. > > There is a good reason not to show them by default - that list is long > enough already, and weird enough for new users. Adding every single > table you have makes it even more complex. So perhaps adding it, but not > by default, enabled by a checkbox? > That's something I already heard at Solutions Linux 2008. I talked with someone who has this kind of issues. This guy has lots of tables, so his type combo box is really huge, and becomes actually unusable. Table types are perfectly valid and we need to have them, but the combo box becomes (is already?) unusable. We probably should think about designing if differently : for example a text box and a button. The text box allows someone to quickly, but manually, put a type, and the button allows to open a new window with a listbox containing all types and two checkboxes, one to add/remove array types, another one to add/remove table types. -- Guillaume. http://www.postgresqlfr.org http://dalibo.com
On Feb 13, 2008 2:56 PM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > That's something I already heard at Solutions Linux 2008. I talked with > someone who has this kind of issues. This guy has lots of tables, so his > type combo box is really huge, and becomes actually unusable. > > Table types are perfectly valid and we need to have them, but the combo > box becomes (is already?) unusable. We probably should think about > designing if differently : for example a text box and a button. The text > box allows someone to quickly, but manually, put a type, and the button > allows to open a new window with a listbox containing all types and two > checkboxes, one to add/remove array types, another one to add/remove > table types. OK, so I'm thinking for now then we should just remove table types altogether - as Peter reports, we only show the array types anyway, so I guess few people actually want to use them given that we've had no prior complaints. We can add a TODO to redesign things later. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com The Oracle-compatible database company
Dave Page wrote: > On Feb 13, 2008 2:56 PM, Guillaume Lelarge <guillaume@lelarge.info> wrote: >> That's something I already heard at Solutions Linux 2008. I talked with >> someone who has this kind of issues. This guy has lots of tables, so his >> type combo box is really huge, and becomes actually unusable. >> >> Table types are perfectly valid and we need to have them, but the combo >> box becomes (is already?) unusable. We probably should think about >> designing if differently : for example a text box and a button. The text >> box allows someone to quickly, but manually, put a type, and the button >> allows to open a new window with a listbox containing all types and two >> checkboxes, one to add/remove array types, another one to add/remove >> table types. > > OK, so I'm thinking for now then we should just remove table types > altogether - as Peter reports, we only show the array types anyway, so > I guess few people actually want to use them given that we've had no > prior complaints. Agreed. > We can add a TODO to redesign things later. Yes, please do. //Magnus
Dave Page a écrit : > On Feb 13, 2008 2:56 PM, Guillaume Lelarge <guillaume@lelarge.info> wrote: >> That's something I already heard at Solutions Linux 2008. I talked with >> someone who has this kind of issues. This guy has lots of tables, so his >> type combo box is really huge, and becomes actually unusable. >> >> Table types are perfectly valid and we need to have them, but the combo >> box becomes (is already?) unusable. We probably should think about >> designing if differently : for example a text box and a button. The text >> box allows someone to quickly, but manually, put a type, and the button >> allows to open a new window with a listbox containing all types and two >> checkboxes, one to add/remove array types, another one to add/remove >> table types. > > OK, so I'm thinking for now then we should just remove table types > altogether - as Peter reports, we only show the array types anyway, so > I guess few people actually want to use them given that we've had no > prior complaints. > +1 > We can add a TODO to redesign things later. > What do you think of the UI I mention in my previous mail ? if it feels OK to you (and others), I'll have a look at it. -- Guillaume. http://www.postgresqlfr.org http://dalibo.com
On Feb 13, 2008 3:06 PM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > What do you think of the UI I mention in my previous mail ? if it feels > OK to you (and others), I'll have a look at it. Probably best to hold off for now - redesigning the table & child dialogues is on the todo for this cycle anyway. Of course this would still be an issue various other dialogues, so perhaps we need a custom type selector control which we can populate itself appropriately offer nice ways to select what to include. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com The Oracle-compatible database company
Prerequisites: pgAdmin 1.8.2, Windows Xp SP2, Postgres 8.3.0 Steps to reproduce: 1)Run the following sequence. create table basic_table( a integer, b integer); create table derived_table( c integer ) inherits (basic_table); create table basic_table_b (d integer); alter table derived_table add column d integer; alter table derived_table inherit basic_table_b; 2)Right click on derived_table and select "Scripts->CREATE script". You should see the following text: -- Table: derived_table -- DROP TABLE derived_table; CREATE TABLE derived_table ( -- Inherited: a integer, -- Inherited: b integer, c integer, -- Inherited: d integer ) INHERITS (basic_table, basic_table_b) WITH (OIDS=FALSE); ALTER TABLE derived_table OWNER TO postgres; which is incorrect because "c integer" is followed by "," though it it is at the end of the list. Peter G.
On Feb 15, 2008 11:00 PM, Peter Gagarinov <heartofmars@gmail.com> wrote: > CREATE TABLE derived_table > ( > -- Inherited: a integer, > -- Inherited: b integer, > c integer, > -- Inherited: d integer > ) > INHERITS (basic_table, basic_table_b) > WITH (OIDS=FALSE); > ALTER TABLE derived_table OWNER TO postgres; > > which is incorrect because "c integer" is followed by "," though it it > is at the end of the list. Thanks, fixed in SVN. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com The Oracle-compatible database company
Hello, While playing with inheritence in Postgres 8.3 I've discovered that inherited columns behave differently depending on whether they were merged on not (though it may sound trivial for Postgres gurus). Prerequisites: 1) In this case table beta contains 'truly' inherited column 'a' marked as '-- Inherited' by pgAdmin: create table alpha ( a integer ); create table beta ( ) inherits(alpha); 2) In this case table beta contains inherited & MERGED column 'a' which is also marked as '-- Inherited': create table alpha ( a integer ); create table beta ( a integer ); alter table beta inherit alpha; Merged column behaves differently (compared to 'purely' inherited), namely when column 'a' is dropped in parent table 'alpha' by issuing alter table alpha drop column a; command. In case 1) this command deletes column from table 'beta' while in case2) the column 'a' in table 'beta' remains untouched. Request: Could you please consider marking 'merged' columns as '-- Merged' instead of just '-- Inherited' since this would allow for easy identification of merged columns. Regards, Peter
On Thu, Feb 21, 2008 at 9:56 PM, Peter Gagarinov <heartofmars@gmail.com> wrote: > Could you please consider marking 'merged' columns as '-- Merged' > instead of just '-- Inherited' since this would allow for easy > identification of merged columns. That's not really the correct behaviour as we should reproduce the original SQL - ie. include the column in the definition rather than comment it out. I've committed a patch to fix this - thanks for the report. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com The Oracle-compatible database company