Re: GUI Interface

> -----Original Message-----
> From: Tony Caduto [mailto:tony_caduto@amsoftwaredesign.com]
> Sent: 12 May 2006 16:51
> To: Dave Page; pgsql-general@postgresql.org
> Subject: Re: [GENERAL] GUI Interface
>
> Dave Page wrote:
> > I work in a professional environment in a country (the UK)
> where the
> > cost of a 2Mb leased line could buy you a new laptop every month (a
> > significant amount of money for a small company), and yes,
> I regularly
> > use servers on the other side of the world where the round
> trip time
> > etc. would make a query-per-click interface unusable.
> >
> >
> So you are saying the UK does not have cable or DSL based broadband?

No, I'm saying that a leased line is very expensive. FWIW, SDSL is still
far from being widely available, and DSL only has 256Kb/sec upstream
speed. Domestic DSL lines are generally contended at 50:1 so actually
getting 256Kb/sec upstream, is very unlikely.

> Anyway, if in general you where using  a slow connection such
> as a 56k line wouldn't it make a lot of sense to work on a
> local copy of the database?

Not if it's of any real size.

> When you are working in a LAN environment the pre-loading
> that pgAdmin III does is kind of a pain in the you know what.

OK, now I know you're just trying to slag off pgAdmin. My SQL Server's
here are *significantly* more powerful than my PostgreSQL servers, yet
pgAdmin is far more responsive then Enterprise Manager.

>  I had MS SQL DBAs notice the preloading/caching right away
> and they hated it.
> It really sucks for the function editor as after you open the
> function for the first time it continues to use the cached
> copy until you refresh or save it again.  Joe DBA down the
> hall in some other cube makes a change to a function and with
> pgAdmin III you won't know about it until you manually
> refresh the function, opening it will cause it to use the
> last cached copy and you then go about your business and when
> you save it you wipe out the changes made by DBA #2 .  In a
> perfect situation you would not be doing things like this on
> a production server, but it still happens.  You should at
> least change this behavior for the function editor as it
> makes no sense to be caching the functions ddl.

It is on my todo for the next release. Note that even that still doesn't
protect the user from concurrent edit conflicts.

> All I can say is that if you are used to working with the
> tools that come with commercial DBs they do not behave
> anything like pgAdmin III and you end up cursing everything
> about pgAdmin III.  If you are not used to anything else
> pgAdmin III is great and thats because you don't know what
> you are missing.

I've used Enterprise Manager since before I started with pgAdmin II and
I still curse it to this day.

Regards, Dave.