Re: Two bugs

From: Dave Page <dpage(at)postgresql(dot)org>
To: robins(at)pobox(dot)com
Cc: pgadmin-hackers(at)postgresql(dot)org
Subject: Re: Two bugs
Date: 2007-04-05 09:36:00
Message-ID: 4614C300.1020508@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-hackers

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

In response to

  • Two bugs at 2007-04-05 04:51:21 from Robins

Browse pgadmin-hackers by date

  From Date Subject
Next Message svn 2007-04-05 18:54:12 SVN Commit by hiroshi: r6178 - in trunk/pgadmin3/debugger: . include
Previous Message Dave Page 2007-04-05 09:12:40 pgAdmin packages for Solaris available