Re: Serious bug in edit grid? - Mailing list pgadmin-support

From Chris St Denis
Subject Re: Serious bug in edit grid?
Date
Msg-id 006801c62094$ba845080$6401a8c0@chris
Whole thread Raw
In response to Serious bug in edit grid?  ("Chris St Denis" <Chris@ctgameinfo.com>)
List pgadmin-support
Latest stable version of pgadminIII -- 1.4.1
postgresql 8.0.4 running on FreeBSD 5.4 (from ports)

I do not belive I dropped and readded any columns to this table.
customer_service_attribute_id should have been there as a serial from the
start.

---

Another unrelated bug I'll like to bring up. On connect as an admin with the
extensions installed an error is generated regarding /proc/uptime because
freebsd does not by default have a /proc.

Workaround: install procfs or ignore.
proper solution: supress the error or obtain uptime using another method.

----- Original Message ----- 
From: "Andreas Pflug" <pgadmin@pse-consulting.de>
To: "Chris St Denis" <Chris@ctgameinfo.com>
Cc: <pgadmin-support@postgresql.org>
Sent: Monday, January 23, 2006 3:33 PM
Subject: Re: [pgadmin-support] Serious bug in edit grid?


> Chris St Denis wrote:
>
> > When editing my table contents multiple rows wiht the same value all
> > get changed.
> >
> > Table design:
> >
> > CREATE TABLE customer_service_attributes
> > (
> >   customer_service_attribute_id int4 NOT NULL DEFAULT
> >
nextval('public.cust_srv_features_customer_service_attributes_seq'::text),
> >   _service_id int4 NOT NULL, -- This can be derrived from the attrib
> > ID, but is also here to make queries easier.
> >   service_attr_id int4 NOT NULL,
> >   _customer_id int4 NOT NULL,
> >   customer_service_id int4 NOT NULL,
> >   value text NOT NULL,
> >   CONSTRAINT customer_service_attributes_pkey PRIMARY KEY
> > (customer_service_attribute_id),
> >   CONSTRAINT customer_service_attributes_customer_id_fkey FOREIGN KEY
> > (_customer_id)
> >       REFERENCES customer (customer_id) MATCH SIMPLE
> >       ON UPDATE RESTRICT ON DELETE RESTRICT,
> >   CONSTRAINT customer_service_attributes_customer_service_id_fkey
> > FOREIGN KEY (customer_service_id)
> >       REFERENCES customer_services (customer_service_id) MATCH SIMPLE
> >       ON UPDATE RESTRICT ON DELETE RESTRICT,
> >   CONSTRAINT customer_service_attributes_service_attr_id_fkey FOREIGN
> > KEY (service_attr_id)
> >       REFERENCES service_attribute (service_attr_id) MATCH SIMPLE
> >       ON UPDATE RESTRICT ON DELETE RESTRICT,
> >   CONSTRAINT customer_service_attributes_service_id_fkey FOREIGN KEY
> > (_service_id)
> >       REFERENCES service (service_id) MATCH SIMPLE
> >       ON UPDATE RESTRICT ON DELETE RESTRICT
> > )
> > WITHOUT OIDS;
> >
> >
> > When editing the value feild in rows in the grid changing value x to
> > y, all rows with value x become y. Looking in the query log shows the
> > following
> >
> > STATEMENT:  UPDATE customer_service_attributes SET
> > value='y'::pg_catalog.text WHERE value = 'x'::pg_catalog.text
> >
> > Shouldn't this be refrencing the primary key of
> > customer_service_attribute_id in the where clause? as in
> >
> > STATEMENT:  UPDATE customer_service_attributes SET
> > value='y'::pg_catalog.text WHERE customer_service_attribute_id = 620
> >
> >
> > Am I doing something wrong or is there a massive bug here??
>
>
> Which version?
> We had a recent fix that could hit you when you dropped columns and
> readded some as PK.
>
> Regards,
> Andreas
>
>




pgadmin-support by date:

Previous
From: Tino Wildenhain
Date:
Subject: Re: how to load database from extern files?
Next
From: Francisco Leovey
Date:
Subject: UPDATE on Pgadmin III not honoring DATESTYLE