Thread: pg admin bug - view data
I think there is a bug in the pgadmin view data option for a table. If the table does not have a primary key, pgadmin issues an invalid select. Here is the table definition: CREATE TABLE data_tbl ( packet_rec_id numeric(38) NOT NULL, tag varchar(32) NOT NULL, subtag varchar(32), seq int4 NOT NULL, value text, CONSTRAINT data_uk UNIQUE (packet_rec_id, tag, subtag, seq) ) WITHOUT OIDS; Here is the SQL that PgAdmin issues (from the log file). Notice that the ORDER BY clause does not specify any columns: 2003-11-21 08:24:36 INFO : Running query SELECT * FROM data_tbl ORDER BY ASC 2003-11-21 08:24:36 QUERY : Thread Query SELECT * FROM data_tbl ORDER BY ASC 2003-11-21 08:24:36 QUERY : DEBUG: StartTransactionCommand 2003-11-21 08:24:36 QUERY : DEBUG: AbortCurrentTransaction --- Michael
Michael Shapiro wrote: > I think there is a bug in the pgadmin view data option for a table. If > the table does not have a primary key, pgadmin issues an invalid > select. Here is the table definition: > Yes, you're right, that's a bug; fixed in cvs. Though I consider a table without PK or OID buggy too... :-) We might expand pgAdmin3 to use a unique key as PK replacement. Regards, Andreas
> Yes, you're right, that's a bug; fixed in cvs. > Though I consider a table without PK or OID buggy too... :-) > We might expand pgAdmin3 to use a unique key as PK replacement. phpPgAdmin does the following in order to find a unique row identifier: 1. Looks for a PK 2. Looks for a Unique index. If one is found, editing rows is possible unless the entry in the index for the row is NULL (because there can be multiple NULLs in a unique index) 3. Looks for an OID column. If one exists, editing is possible BUT the update or delete of the row is performed in a transaction and if more than one row is modified then the alteration is rolled back. This is important as OID columns can contain duplicate entries in the case of OID wraparound. You know, phpPgAdmin and pgAdmin really should share a lot more :) I think I'll look at the pgAdmin3 column type alteration code. You might be interested in phpPgAdmin's Find Object code... Actually, are you guys BSD licensed or GPL'd? phpPgAdmin is GPL'd. Chris
> -----Original Message----- > From: Christopher Kings-Lynne [mailto:chriskl@familyhealth.com.au] > Sent: 22 November 2003 02:15 > To: Andreas Pflug > Cc: Michael Shapiro; pgadmin-support@postgresql.org > Subject: Re: [pgadmin-support] pg admin bug - view data > > > You know, phpPgAdmin and pgAdmin really should share a lot more :) Yup :-) > I think I'll look at the pgAdmin3 column type alteration > code. You might be interested in phpPgAdmin's Find Object code... We have Find Object in pga2, though it does little more than search the object heirarchy (everything in pga2 is driven through pgSchema, which is a self-building object hierarchy - basically what you see on the treeview & listview, plus create() and drop() etc. in the relevant places) > Actually, are you guys BSD licensed or GPL'd? phpPgAdmin is GPL'd. Neither, we use the Artistic Licence, the same as Perl. Regards, Dave.
>>Actually, are you guys BSD licensed or GPL'd? phpPgAdmin is GPL'd. > > > Neither, we use the Artistic Licence, the same as Perl. Does that mean our codebases are compatible or not? If so, to what degree? Chris
> We have Find Object in pga2, though it does little more than search the > object heirarchy (everything in pga2 is driven through pgSchema, which > is a self-building object hierarchy - basically what you see on the > treeview & listview, plus create() and drop() etc. in the relevant > places) Ours is a gigantic UNION ALL :P Still, it runs very quickly. Chris
> -----Original Message----- > From: Christopher Kings-Lynne [mailto:chriskl@familyhealth.com.au] > Sent: 22 November 2003 07:54 > To: Dave Page > Cc: Andreas Pflug; Michael Shapiro; pgadmin-support@postgresql.org > Subject: Re: [pgadmin-support] pg admin bug - view data > > > >>Actually, are you guys BSD licensed or GPL'd? phpPgAdmin is GPL'd. > > > > > > Neither, we use the Artistic Licence, the same as Perl. > > Does that mean our codebases are compatible or not? If so, > to what degree? Quite simply I don't know. Anyone else have any idea? Regards, Dave