Thread: Results from testing 1.6.1 rev: 5646:5652M

Results from testing 1.6.1 rev: 5646:5652M

From
Erwin Brandstetter
Date:
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



Re: Results from testing 1.6.1 rev: 5646:5652M

From
Dave Page
Date:
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.




Re: Results from testing 1.6.1 rev: 5646:5652M

From
Erwin Brandstetter
Date:
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


Re: Results from testing 1.6.1 rev: 5646:5652M

From
"Dave Page"
Date:

> ------- 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