Re: [gnome-db] gda and PostgreSQL schemas

[Diego Zuccato <diego otello alma unibo it>]

Vivien Malerba ha scritto:

Seen no answer so far... Since the first was so fast, I think the second 
got lost somewhere... Or just hit the trashcan... :)

> > [...]It could be really
> > useful a "tree" view instead of a "list" view. And it seems it couldn't
> > recognize "ltree" type used in some tables (correctly installed, since
> Can you send me the dictionary it made with that data type? I've never
> used that data type myself.
[Stripped attaches sent in the other mail. Better not to post it in the 
list. If it got lost, I'll resend. The following steps are enough to 
reproduce, anyway]
In a simple case (no schema), it works.
$createdb test
$psql test
test=#create table prova (path ltree, descr char(30));

If I first create a schema, it stops working.
$createdb test2
$psql test2
test=#create schema test;
test=#create table test.prova (path ltree, descr char(30));

(when trying to load this db metadata, mergeant says it can't find ltree 
data type).

> > PG doesn't complain), leading to a corrupted dict file.
> > In my program I'm using many cross-schema queries. Should I expect troubles?
> You may have some trouble if you have tables with the same name in
> different schemas and if these schemas are part of the search_path...
> I have on my todo list to handle correctly schemas...
What if I use the (I think PG-standard) schema.tablename notation?

> > PS: is there something "standard" to handle tree structures
> > (efficiently... can't load all 20K rows at start...) or should I create
> > my own widget?
> Which kind of tree structures do you have? Is it to be used with the
> ltree data type?
In my case, yes. I'm using ltree to handle variable-depth trees 
(geographic position of caves: continent->state->region->city->... ). 
But a general-purpose widget could be useful for many things: directory 
browser (a filesystem is a DB, after all...  :)  ), 
db-schema-table-field & so on.

I already have coded a GTK_TREE_STORE filler: it's a callback for every 
row returned from the query. It receives the current row and the 
tree_store to update, and appends to the correct parent the new data 
(using "ORDER BY path USING <@", I could get O(nlogn) complexity, while 
in general it's O(n2), but maybe using hash tables it's around O(n)...). 
The drawback is that it fills the WHOLE tree... Having around 20K 
locations you see it becomes quite unmanageable (some hours just to 
start up)...
What could be really useful is an "infrastructure widget", that gets 
filled while the user proceeds: when he clicks "continent", he gets all 
the nations in that continent & so on for regions in nations, cities in 
regions...
Such a widget (really just a gtk_tree_view with some extra data 
attached) should be in gnome-db, IMVHO.
What do you think?

BYtE,
 Diego.