Hi all,

Couldn't find these two bugs in the known bugs list so am posting here.

Issue 1: When a view is changed (via SQL or any other source) and when one
tries to 'View all' the View, the column headers are blank. Refreshing the
'Views' parent twice (one when this view disappears, and the second time
when it reappears) solves the problem. Is it possible that (while the user
clicks on 'View all') ... when pgadmin notices that a view has changed, it
automatically refreshes the structure ?

Issue 2: PgAdmin has repeatedly been oddly singling out a specific function
( lets name it a) in my database to be renamed into the last used function
(lets name it b). That means, many times when PgAdmin crashes, and when I
restart, instead of finding two functions.
a(a_param1)
b(b_param1, b_param2)

Instead I find

b(a_param1)
b(b_param1, b_param2)

(and of course function a is now disappeared). One perculiar thing is that
although function b may vary depending on what i am working on while pgadmin
crashes, function a is almost always the same !!


Platform: Win XP
Language: English
Distribution: Postgresql 8.2.3
Version: 1.6.2
Debug option: Unable to do this, its a win environment and i didnt compile
this version.

If there is anything else I could provide, please do tell.

--
Robins

Robins wrote:
> Hi all,
>
> Couldn't find these two bugs in the known bugs list so am posting here.
>
> Issue 1: When a view is changed (via SQL or any other source) and when
> one tries to 'View all' the View, the column headers are blank.
> Refreshing the 'Views' parent twice (one when this view disappears, and
> the second time when it reappears) solves the problem. Is it possible
> that (while the user clicks on 'View all') ... when pgadmin notices that
> a view has changed, it automatically refreshes the structure ?

The view can't change what it returns though, as you'll get an error
from PostgreSQL like:

-- Executing query:
CREATE OR REPLACE VIEW bar_view AS
SELECT 'a' AS cola, 'b' AS cola

ERROR: cannot change name of view column "col1"
SQL state: 42P16

The only way to do what you describe is to drop the view through SQL and
create a new one with the same name. That will always screw up pgAdmin
as it doesn't know you've done that unless you do it through the UI. The
only way round this would be to check for changes like this on every
action, but that would make pgAdmin unusable for users on slower network
connections as every time the tried to do anything (even select a
treeview node), one or more round trips to the server would be made.

The refresh twice thing is happening (I imagine) because you are
refreshing the view node itself, which vanishes because the original
view no longer exists. You then refresh the Views node which repopulates
all of the views under it, thus picking up the new one. In this
situation, just refresh the Views node.

> Issue 2: PgAdmin has repeatedly been oddly singling out a specific
> function ( lets name it a) in my database to be renamed into the last
> used function (lets name it b). That means, many times when PgAdmin
> crashes, and when I restart, instead of finding two functions.
> a(a_param1)
> b(b_param1, b_param2)
>
> Instead I find
>
> b(a_param1)
> b(b_param1, b_param2)
>
> (and of course function a is now disappeared). One perculiar thing is
> that although function b may vary depending on what i am working on
> while pgadmin crashes, function a is almost always the same !!

Well first off, pgAdmin should *not* be crashing so please describe what
you are doing when it does.

Secondly I honestly don't see any way in which pgAdmin would randomly
rename one of your functions - that would involve it generating and
executing an ALTER FUNCTION statement. Whilst I can imagine a bug that
causes a crash or odd error, I have a hard time believing there is one
that can randomly generate and execute perfectly valid SQL statements!

Are you sure you're not getting two dialogues mixed up? If not, please
describe exactly what you are doing.

Regards, Dave

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate