Thread: The bugs are getting harder to find...
pgAdmin: 1.4.12
PostgreSQL: 7.3
OS: W2K SP2
1)
Edit a view and you loose any comments that you have made about it. Have not tested this but it probably means that you loose any rules that you have made too which is even worse!
2)
Trigger functions that take parameters show up as ??????? and not the text typed. For example CREATE TRIGGER trig_btrim_cap BEFORE INSERT OR UPDATE ON public.tbl_country FOR EACH ROW EXECUTE PROCEDURE btrim_cap('s_name'); is shown by pgAdmin as CREATE TRIGGER trig_btrim_cap BEFORE INSERT OR UPDATE ON public.tbl_country FOR EACH ROW EXECUTE PROCEDURE btrim_cap(??????? which is not what was originally entered.
Obviously I have first created a function named btrim_cap: CREATE FUNCTION public.btrim_cap() RETURNS trigger AS 'util_funcs.so' LANGUAGE 'c' VOLATILE; I think pgAdmin is trying to do something smart and recognise the data types for the functions available.
3)
Leading on from bug 2) exposes another annoying bug. pgAdmin doesn't report the loadable module that contains the function.
When I create a function that is found in a loadable library e.g. CREATE FUNCTION public.btrim_cap() RETURNS trigger AS 'util_funcs.so' LANGUAGE 'c' VOLATILE; pgAdmin always returns the statement without the loadable module e.g. CREATE FUNCTION public.btrim_cap() RETURNS trigger AS 'btrim_cap' LANGUAGE 'c' VOLATILE;
Regards
Donald
Hi Donald
-----Original Message-----
From: Donald Fraser [mailto:demolish@cwgsy.net]
Sent: 17 December 2002 16:54
To: pgadmin-support@postgresql.org
Subject: [pgadmin-support] The bugs are getting harder to find...pgAdmin: 1.4.12PostgreSQL: 7.3OS: W2K SP21)Edit a view and you loose any comments that you have made about it. Have not tested this but it probably means that you loose any rules that you have made too which is even worse!
You don't lose the comments, it just doesn't refresh the cache to get the new ones (fixed in the latest snapshot). You are right about the rules though, but a warning is given and the user is given the option to abort. I have reworded the warning in the snapshot though as it was definately a 2AM one!! The real fix for this is substantial work which I probably won't do for 2 reasons - I'm concentrating on pgAdmin III now, and I expect create or replace view to be added to PostgreSQL 7.4.
2)Trigger functions that take parameters show up as ??????? and not the text typed. For example CREATE TRIGGER trig_btrim_cap BEFORE INSERT OR UPDATE ON public.tbl_country FOR EACH ROW EXECUTE PROCEDURE btrim_cap('s_name'); is shown by pgAdmin as CREATE TRIGGER trig_btrim_cap BEFORE INSERT OR UPDATE ON public.tbl_country FOR EACH ROW EXECUTE PROCEDURE btrim_cap(??????? which is not what was originally entered.Obviously I have first created a function named btrim_cap: CREATE FUNCTION public.btrim_cap() RETURNS trigger AS 'util_funcs.so' LANGUAGE 'c' VOLATILE; I think pgAdmin is trying to do something smart and recognise the data types for the functions available.
I need to look into this one in more detail. Unfortunately I'm quite busy at the moment but leave it with me.
3)Leading on from bug 2) exposes another annoying bug. pgAdmin doesn't report the loadable module that contains the function.When I create a function that is found in a loadable library e.g. CREATE FUNCTION public.btrim_cap() RETURNS trigger AS 'util_funcs.so' LANGUAGE 'c' VOLATILE; pgAdmin always returns the statement without the loadable module e.g. CREATE FUNCTION public.btrim_cap() RETURNS trigger AS 'btrim_cap' LANGUAGE 'c' VOLATILE;
That's the best info we can get from the PostgreSQL catalogues. It only stores the module name in the compiled binary code for the function which we can't easily decode client side :-(
Regards, Dave.
-----Original Message-----
From: Donald Fraser [mailto:demolish@cwgsy.net]
Sent: 17 December 2002 16:54
To: pgadmin-support@postgresql.org
Subject: [pgadmin-support] The bugs are getting harder to find...2)Trigger functions that take parameters show up as ??????? and not the text typed. For example CREATE TRIGGER trig_btrim_cap BEFORE INSERT OR UPDATE ON public.tbl_country FOR EACH ROW EXECUTE PROCEDURE btrim_cap('s_name'); is shown by pgAdmin as CREATE TRIGGER trig_btrim_cap BEFORE INSERT OR UPDATE ON public.tbl_country FOR EACH ROW EXECUTE PROCEDURE btrim_cap(??????? which is not what was originally entered.Obviously I have first created a function named btrim_cap: CREATE FUNCTION public.btrim_cap() RETURNS trigger AS 'util_funcs.so' LANGUAGE 'c' VOLATILE; I think pgAdmin is trying to do something smart and recognise the data types for the functions available.
Hi Donald,
I found some time last night and this bug is now fixed as far as I can tell. Please try the latest snapshot.
Regards, Dave.
Hi Dave,
that fixed one problem and created a minor one when you don't have any parameters - you get a single quote mark ('). Minor minor bug and I can live with that.
I am using the software every day now and I envisage I will continue to do so for the next month. Hence I am really happy that it's pretty stable now.
I have discovered one major bug - a crash (memory could not be read error) when executing a SQL query on a view. Unfortunately it's not easy to reproduce for you without sending you a lot of table information, views, rules, PL/SQL functions, trigger functions etc. The basic query is very simple - an INSERT INTO view statement. The view obviously has rules on it and it inserts data into more than one table. I'm guessing that may be the return result of the query is something that the MDAC driver is not expecting for an INSERT INTO query and therefore crashes!
Data is actually entering the database, therefore the query is arriving at the server, executing and completing. Hence why I think it is the return result that is causing the crash. When I run the query from psql on the server I get the following returned.
insert_persnl_user
--------------------
(0 rows)
--------------------
(0 rows)
So I am getting a column returned from the last function (insert_persnl_user) that is run, which is weird as this is not the last statement - a normal INSERT INTO is the last statement to be run in one of the rules.
Anyway don't worry about it as I can ssh into the server and issue SQL commands with psql to test stuff when the above is going to cause a problem.
I might have another look at it and see if I can reproduce it without a complex database behind the scene.
Regards
Donald.
----- Original Message -----From: Dave PageSent: Friday, December 20, 2002 8:31 AMSubject: RE: [pgadmin-support] The bugs are getting harder to find...-----Original Message-----
From: Donald Fraser [mailto:demolish@cwgsy.net]
Sent: 17 December 2002 16:54
To: pgadmin-support@postgresql.org
Subject: [pgadmin-support] The bugs are getting harder to find...2)Trigger functions that take parameters show up as ??????? and not the text typed. For example CREATE TRIGGER trig_btrim_cap BEFORE INSERT OR UPDATE ON public.tbl_country FOR EACH ROW EXECUTE PROCEDURE btrim_cap('s_name'); is shown by pgAdmin as CREATE TRIGGER trig_btrim_cap BEFORE INSERT OR UPDATE ON public.tbl_country FOR EACH ROW EXECUTE PROCEDURE btrim_cap(??????? which is not what was originally entered.Obviously I have first created a function named btrim_cap: CREATE FUNCTION public.btrim_cap() RETURNS trigger AS 'util_funcs.so' LANGUAGE 'c' VOLATILE; I think pgAdmin is trying to do something smart and recognise the data types for the functions available.Hi Donald,I found some time last night and this bug is now fixed as far as I can tell. Please try the latest snapshot.Regards, Dave.
-----Original Message-----
From: Donald Fraser [mailto:demolish@cwgsy.net]
Sent: 20 December 2002 16:58
To: pgadmin-support@postgresql.org
Subject: Re: [pgadmin-support] The bugs are getting harder to find...Hi Dave,that fixed one problem and created a minor one when you don't have any parameters - you get a single quote mark ('). Minor minor bug and I can live with that.
Aww nuts. Sorry, fixed now (I can't live with it :-) ). The fix affects only pgSchema.dll, so you can just update that.
I am using the software every day now and I envisage I will continue to do so for the next month. Hence I am really happy that it's pretty stable now.
Cool, glad you're finding it useful.
I have discovered one major bug - a crash (memory could not be read error) when executing a SQL query on a view. Unfortunately it's not easy to reproduce for you without sending you a lot of table information, views, rules, PL/SQL functions, trigger functions etc. The basic query is very simple - an INSERT INTO view statement. The view obviously has rules on it and it inserts data into more than one table. I'm guessing that may be the return result of the query is something that the MDAC driver is not expecting for an INSERT INTO query and therefore crashes!
Sounds like it for 2 reasons. Firstly, pgAdmin relies on MDAC to tell it if there are results to display, or if it was a non-query (MDAC has no concept of scalar queries). Secondly, one of the nice things about Visual Basic is that you can always blame invalid memory locations etc. on VB itself or one of the libraries in use, because VB has no memory access to speak of. You cannot create invalid pointers as you can in C/C++.
Data is actually entering the database, therefore the query is arriving at the server, executing and completing. Hence why I think it is the return result that is causing the crash. When I run the query from psql on the server I get the following returned.insert_persnl_user
--------------------
(0 rows)So I am getting a column returned from the last function (insert_persnl_user) that is run, which is weird as this is not the last statement - a normal INSERT INTO is the last statement to be run in one of the rules.Anyway don't worry about it as I can ssh into the server and issue SQL commands with psql to test stuff when the above is going to cause a problem.I might have another look at it and see if I can reproduce it without a complex database behind the scene.
Please do if you get time. I'll happily look for a workaround. I don't want to spend time developing pgAdmin III further, but bug fixes are another matter.
Regards, Dave.