Thread: Results from testing 1.6.1 rev: 5646:5652M
Hi developers! Hi Dave! After the release is before the release, huh? :) Testing 1.6.1 rev: 5646:5652M, client Win XP. Host Debian Sarge, PG 8.1.4 - Cancel in "View Data Options" now works as expected. I have seen no more crashes. - Find and Replace Replacing now works as expected, I think you have nailed the endless loop for good. However, there seem to be issues with "Regular expressions"-search. After extensive testing (symptoms were not coherent) I think I found the root of the problem: Looks like an undead echo of the umlaut / non-latin1 issue. Every appearance of a German umlaut makes the selection fall back by 1 character. 'Replace' will stop working after the first occurrance of an umlaut. I would guess your algorithm counts bytes instead of characters and 2-byte-characters mess with the count. Try searching this text, with "Regular expressions" checked, seach for 'x' or '[[:digit:]]x' ' 54321x 54321x ä 54321x 54321x ö 54321x 54321x ü 54321x 54321x ß 54321x 54321x no umlaut here 54321x 54321x ' Concerning the options "From the top" and "From the cursor": That seems to work as described now. As I mentioned before, my preferred solution would be to wrap around searches: start at the cursor, continue from the top (maybe after asking) until cycle is complete, like vim or Firefox do it. Would make this option dispensible. If you decide to keep it, I would name it "From top" and "From cursor". - New: OUT parameters of functions are mistaken for IN-Parameters. Functions with OUT-Parameters are incorretly displayed. Operations on it will fail with accordingly incorrect error messages. Test case: CREATE OR REPLACE FUNCTION f_test(IN a integer, OUT b text) AS $BODY$ BEGIN b := 1; END; $BODY$ LANGUAGE 'plpgsql' VOLATILE; This function will be displayed under "Procedures" as "f_test(integer, text)" in the object tree. Should be "f_test(integer)" Deleting it from the object tree will fail with the accordingly incorrect error message: An error has occured Fehler: Funktion f_test(integer, text) existiert nicht. Meaning: Error: Function f_test(integer, text) does not exist. Trying to change properties per dialogue with fail as well. Interestingly, changing the Comment on the function works alright (expected this to fail as well.) I think this issue has been present in previous releases, but I did not bother to test. BTW: what exactly makes a procedure a procedure and not a function? OUT-parameters, right? I wouldn't mind, if functions and procedures were merged in the object tree. Regards Erwin
Erwin Brandstetter wrote: > - Find and Replace > Replacing now works as expected, I think you have nailed the endless > loop for good. > However, there seem to be issues with "Regular expressions"-search. > Unfortunately that boils down to a wxWidgets bug which I've logged with them. I have a possible idea for a workaround, but it's gonna take some investigation. ... > This function will be displayed under "Procedures" as "f_test(integer, > text)" in the object tree. Should be "f_test(integer)" > Deleting it from the object tree will fail with the accordingly > incorrect error message: > An error has occured > Fehler: Funktion f_test(integer, text) existiert nicht. > Meaning: Error: Function f_test(integer, text) does not exist.> > Trying to change properties per dialogue with fail as well. > Interestingly, changing the Comment on the function works alright > (expected this to fail as well.) > I think this issue has been present in previous releases, but I did not > bother to test. Fixed now - thanks. > BTW: what exactly makes a procedure a procedure and not a function? > OUT-parameters, right? Yes - and we don't recommend use of return values from a procedure. > I wouldn't mind, if functions and procedures were merged in the object > tree. We keep them seperate as they help give users of certain other DBMS's (who may not be familar with functions as we know them) a warm and fuzzy feeling :-) Regards, Dave.
Hi Dave! dpage@postgresql.org wrote: > Erwin Brandstetter wrote: >> BTW: what exactly makes a procedure a procedure and not a function? >> OUT-parameters, right? > Yes - and we don't recommend use of return values from a procedure. To clarify: "we" stands for the PostgreSQL developers? Or pgAdmin developers? It's not a rare case of pluralis majestatis, is it? :-o >> I wouldn't mind, if functions and procedures were merged in the >> object tree. > > We keep them seperate as they help give users of certain other DBMS's > (who may not be familar with functions as we know them) a warm and > fuzzy feeling :-) I feel dumb. The fuzzy-feelers come from .. mysql .. or oracle? Regards Erwin
> ------- Original Message ------- > From: Erwin Brandstetter <brandstetter@falter.at> > To: dpage@postgresql.org > Sent: 18/11/06, 15:06:23 > Subject: Re: [pgadmin-support] Results from testing 1.6.1 rev: 5646:5652M > > To clarify: "we" stands for the PostgreSQL developers? Or pgAdmin > developers? It's not a rare case of pluralis majestatis, is it? :-o Errr partly :-) Myself, and and some actual knowledgeable people who for various reasons I cannot name right now! > I feel dumb. The fuzzy-feelers come from .. mysql .. or oracle? Oracle. /D