Skip site navigation (1) Skip section navigation (2)

Re: Working oin pgAdmin2

From: Dave Page <dpage(at)vale-housing(dot)co(dot)uk>
To: "'jm(dot)poure(at)freesurf(dot)fr'" <jm(dot)poure(at)freesurf(dot)fr>
Cc: pgadmin-hackers(at)postgresql(dot)org
Subject: Re: Working oin pgAdmin2
Date: 2002-02-24 22:46:06
Message-ID: FED2B709E3270E4B903EB0175A49BCB10475F3@dogbert.vale-housing.co.uk (view raw or flat)
Thread:
Lists: pgadmin-hackers

> -----Original Message-----
> From: Jean-Michel POURE [mailto:jm(dot)poure(at)freesurf(dot)fr] 
> Sent: 24 February 2002 21:23
> To: Dave Page
> Cc: pgadmin-hackers(at)postgresql(dot)org
> Subject: Re: [pgadmin-hackers] Working oin pgAdmin2
> 
> 
> Le Dimanche 24 Février 2002 21:19, Dave Page a écrit :
> > If a developer working on pgSchema cannot code the required 
> SQL, then 
> > this is *not* the project for him to be hacking. That's 
> like a cowboy 
> > who can't use a lassoo...
> 
> Let's say a French man without a baguette. Oh, now I see...

I prefer crepes (au chocolat - is that right? It's about 14 years since I
did French at school), but that's just me :-)

> IMHO, this is not the question of knowing how to write SQL or 
> not. It would 
> just be great to query legacy databases using pgAdmin2. This 
> will help me 
> learn new things and improve my skills.

Learning more is great, but pgSchema is so totally PostgreSQL specific, that
I think we'd be far better adding new classes to handle ODBC connections to
*any* database. The level of integration would be far less, but you could
still browse tables, data, indexes and views. And it would work with any
ODBC datasource.

What I will not do, is sacrifice PostgreSQL functionality just to allow
access to other dbms's.

> I only have the impression that if we move SQL out of 
> Views.cls to pgViews, 
> and so on, we could consider pgViews to be a PostgreSQL 
> provider. Let's call 
> this wheatever we like : SQL provider, SQL parser, SQL 
> abstract layer. I 
> prefer "provider" as this is the term used by libgda.

The two types of class go hand in hand and will not work without each other.
In an object library such as pgSchema, the classes work in pairs - one
(pgView) provides the basic type, and one (Views) has the responsibility of
maintaining the collection of objects of that type. 

An example is the Field/Fields classes in a Recordset.

In pgSchema, these pairs of classes *are* the abstration layer, and they are
very PostgreSQL specific. For example, how many dbms's have oids? How many
have sequences with the same properties as PostgreSQL?

Another problem, is that other dbms's may not share the same object
hierarchy as PostgreSQL. For example, Oracle has Schemas which add a new
level into the hierarchy. When PostgreSQL adds support for Schemas in 7.3,
we will add 2 classes for them, and move some existing classes (tables,
functions, views etc.) into there, and leave others (operators, types etc)
where they are. That hierarchy will then not be compatible with Informix SE
for example.

I think the most effective way to go would be to write new classes
pgSchema.ODBCServer, pgSchema.ODBCTables, pgSchema.ODBCTable, and have an
ODBCServers collection at the top of the hierarchy, next to pgServer. This
can then provide a hierarchy that is compatible with the sort of data we'd
expect from an ODBC driver. In the future we could add an OLEDBServers
collection in a similar vein.

> 
> In between :
> 1) I still don't know how to refresh treeview when triggers 
> change tables.

Search for the current trigger node as we do when we search for a table node
when renaming and delete it. Then search for the new table node, and add the
trigger node to the Triggers sub node. I have never done this so I have no
code for you to copy, only the existing code to locate nodes.

> 2) PostgreSQL 7.2 internals are really UTF-8, provided that 
> the database is 
> Unicode. This is great for programming server-side. Unfortunately, 
> highlightBox is not really UTF-8 compatible.
> 
> Now, my problem is that Functions need to be written in 
> UTF-8. Yes, my 
> friend, you read it. I can't even write an "é" or anything 
> like "français" in 
> PLpgSQL code. During all the afternoon I fixed such errors in my code.
> 
> So what should we do? Buy some good utf-8 controls? 

Certainly not. That opens a whole new can of licencing problems. Can we
write anything ourselves? Currently we'd need to fix the ListView, Textbox &
RTFTextbox...

> Migrate to KDE3?

Have you tried compiling it from source? Takes forever... Besides, how's
your C/C++?

> Invest 
> in $M new VB for cowboys? 

Well as soon as my supplier get their fingers out, I'll have 4 copies of
visual studio.NET for us here, but with all I've read about vb.NET, I'm very
dubious about porting pgAdmin II to it.

I've read in a number of places that it's so subtley different to VB6, that
many experienced developers might find it easier to learn C# from scratch.

And we should have a C# compiler and classes for Linux within the next few
months....

> Buy a new 2000 euros lassoo?

Euros? Don't mention them to an Englishman - you're liable to get abuse back
;-)

/Dave.

Responses

pgadmin-hackers by date

Next:From: Jean-Michel POUREDate: 2002-02-24 23:06:30
Subject: Re: Working oin pgAdmin2
Previous:From: Dave PageDate: 2002-02-24 22:10:19
Subject: Re: Escaping quotes and double-quotes problem

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group