[pgadmin-support] [BUG] ?
I was having a lot of trouble the other day and thanks to Tom Lane for his help in getting me up and running. I did find however that pgAdminII 1.4.12 did not drop triggers properly. I've enclosed a file which contains the db schema. Although, I couldn't get it to install the plpgsql language and create the database in pgAdminII so I had to create those on the command line. geoff@emsdev:~$ createdb test geoff@emsdev:~$ createlang plpgsql test bug === In pgAdmin, if you drop the function first, and refresh the schema, it shows that the trigger no longer exists on the table blah. However, you would still see the trigger using the psql interface and will have to drop it here otherwise you get cache lookup failed errors and can't install the trigger again as it already exists. If you drop the trigger first, this works fine. So I guess I'm saying you need to drop the trigger explicitly rather than doing it via dropping the function. Is this a feature or a bug? ;o) Sorry if this has been made aware... kind regards Geoff Ellis Metalogic PLC Burnsall Road Coventry UK. +44(0)2476678484 test.sql Description: Binary data ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgadmin-support] Error installing pgadmin II on Windows 98
Dave, Thanks! I did install the SDK...after going back and installing the core, everything works fine. For the record, this only occured under Windows 98 first edition, the SE install went fine. I appreciate your time on this. pgadmin is a great tool! Thanks, John Dave Page said: > When you installed MDAC, did you get the SDK? If so, that doesn't > include the core components. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgadmin-support] Error installing pgadmin II on Windows 98
> -Original Message- > From: John Wells [mailto:[EMAIL PROTECTED]] > Sent: 16 January 2003 13:24 > To: Dave Page > Cc: [EMAIL PROTECTED] > Subject: Re: [pgadmin-support] Error installing pgadmin II on > Windows 98 > > > Dave, > > Thanks! I did install the SDK...after going back and > installing the core, everything works fine. Glad to hear it :-) > For the record, this only occured under Windows 98 first > edition, the SE install went fine. Yeah, I think SE included MDAC. > I appreciate your time on this. pgadmin is a great tool! Thanks. Regards, Dave. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[pgadmin-support] Bug with foreign keys
Hiya Dave,
hope you had a good new years and all
that.
I know you're busy, probably working on the new
version or something.
Anyway found another bug in pgAdmin.
When you add foreign key constraints pgAdmin
doesn't always tell the truth about them. This seems to be the case only when
you have more than one.
The following example:
CREATE TABLE "tbl_useraudit" (
"id_user" int4 NOT NULL,
"id_contrib" int4 NOT NULL,
"id_editedby" int4 NOT NULL,
"dt_edited" timestamp (0) without time zone NOT NULL,
CONSTRAINT "tbl_useraudit_pkey" PRIMARY KEY
("id_user", "dt_edited"),
CONSTRAINT "fkey_user" FOREIGN KEY
("id_user") REFERENCES "tbl_user" ("id") ON DELETE CASCADE ON UPDATE RESTRICT DEFERRABLE INITIALLY
DEFERRED,
CONSTRAINT
"fkey_editedby" FOREIGN KEY ("id_editedby") REFERENCES "tbl_user" ("id")
ON DELETE RESTRICT ON UPDATE RESTRICT DEFERRABLE INITIALLY
DEFERRED
) WITHOUT OIDS;
Produces the following display in
pgAdmin:
-- Table: public.tbl_useraudit
CREATE TABLE public.tbl_useraudit (
id_user int4 NOT NULL,
id_contrib int4 NOT NULL,
id_editedby int4 NOT NULL,
dt_edited timestamp NOT NULL,
CONSTRAINT tbl_useraudit_pkey PRIMARY KEY (id_user,
dt_edited),
CONSTRAINT fkey_editedby FOREIGN KEY (id_editedby)
REFERENCES tbl_user (id) ON DELETE CASCADE ON UPDATE RESTRICT DEFERRABLE
INITIALLY DEFERRED,
CONSTRAINT fkey_user FOREIGN KEY (id_user)
REFERENCES tbl_user (id) ON DELETE CASCADE ON UPDATE RESTRICT DEFERRABLE
INITIALLY DEFERRED
) WITHOUT OIDS;
You will notice that ON DELETE CASCADE is displayed
for both constraints. This is incorrect given the original definition. I checked
the output from pg_dumpall on the backend and it gives the correct definition
hence I'm guessing pgAdmin is at fault.
Regards
Donald
Re: [pgadmin-support] [BUG] ?
> -Original Message- > From: Geoff Ellis [mailto:[EMAIL PROTECTED]] > Sent: 16 January 2003 12:23 > To: [EMAIL PROTECTED] > Cc: Steve Pitchford; Steve Baker > Subject: [pgadmin-support] [BUG] ? > > > I was having a lot of trouble the other day and thanks to Tom > Lane for his help in getting me up and running. I did find > however that pgAdminII 1.4.12 did not drop triggers properly. > > I've enclosed a file which contains the db schema. Although, > I couldn't get it to install the plpgsql language and create > the database in pgAdminII so I had to create those on the > command line. > > > geoff@emsdev:~$ createdb test > geoff@emsdev:~$ createlang plpgsql test > > bug > === > > In pgAdmin, if you drop the function first, and refresh the > schema, it shows that the trigger no longer exists on the > table blah. However, you would still see the trigger using > the psql interface and will have to drop it here otherwise > you get cache lookup failed errors and can't install the > trigger again as it already exists. > > If you drop the trigger first, this works fine. So I guess > I'm saying you need to drop the trigger explicitly rather > than doing it via dropping the function. > > Is this a feature or a bug? ;o) Hi Geoff, I think this falls somewhere in between :-). pgAdmin will happily drop the function (because it relies on PostgreSQL to prevent it if required), but then will not show the trigger because the query it uses has an inner join to the pg_proc entry for the (now missing) function. I'm not particularly compelled to find a for this as the problem no longer exists in PostgreSQL 7.3 which prevents the dropping of items with dependencies by default, and to be honest, I really don't have time right now anyway :-( Thanks for making me aware of the problem however. Regards, Dave. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
