Vivien Malerba wrote:
>> Second, what is the point of all the "Select 1..." queries after the
>> "deallocate"? There are two of them for every column in the table
>> referenced by the prepared statement (created by the postgres provider's
>> implementation of gda_query_execute). They do not produce meaningful
>> results when executed in PostgreSQL's psql client. The where condition
>> appears to be trying to check for unique and primary key constraints.
>> However, the "1" in the select fields is a constant!
>>
>
> It seems the "SELECT 1..." query is sent whenever
> gda_data_model_describe_column() is called, and it can be optimized to
> be called only once...
>
But what information does it provide? Here is a sample session from psql:
issue001_db=# \d+ slots
Table "public.slots"
Column | Type | Modifiers | Description
-------------------+------------------------+-----------+-------------
slot_id | integer | not null |
obj_guid | character(32) | not null |
name | character varying(500) | not null |
slot_type | integer | not null |
int64_val | bigint | |
string_val | character varying(500) | |
double_val | bigint | |
timespec_val | date | |
guid_val | character(32) | |
numeric_val_num | bigint | |
numeric_val_denom | bigint | |
Indexes:
"slots_pkey" PRIMARY KEY, btree (slot_id)
Has OIDs: no
issue001_db=# SELECT 1 FROM pg_catalog.pg_class c,
pg_catalog.pg_constraint c2, pg_catalog.pg_attribute a WHERE c.relname =
'slots' AND c.oid = c2.conrelid and a.attrelid = c.oid and c2.contype =
'P' and c2.conkey[1] = a.attnum and a.attname = 'slot_id';
?column?
----------
(0 rows)
There is not a single row returned by this query. 'slot-id' is the
primary key column, which seems to be something this query might be
looking for. Does this possibly behave differently in an older version
of PostgreSQL? I am using 8.2.6.
> However, I'm in the process of modifying the way database providers
> are implemented so I'll do a full review of the PostgreSQL's provider
> implementation in the near future and won't work on it before that
> except if you really need it.
>
> Also, my understanding is that you are trying to make the Libgda
> backend of Gnucash working correctly, if I'm wrong, forget the rest of
> this paragraph. As I'm currently working on the V4 version of Libgda,
> I've started to introduce some API changes to make the library easier
> to use and understand and easier to implement providers, but with some
> API changes, so I would suggest that you work on that backend with the
> still-unreleased V4 version which is already useable to avoid having
> to make yet another port to V4.
>
>
>> Should I file a bug against the postgresql provider?
>>
>
> Yes, please, so I can keep a reminder of that specific problem.
>
Bug513149
http://bugzilla.gnome.org/show_bug.cgi?id=513149
I am testing the gda backend for gnucash. I would be happy to use the
unstable version 4.0 to try it. Where do I find the code? I did not
see a branch for working on 4.0. Is it trunk I should try for this?
> Regards,
>
> Vivien
>
Mark
_______________________________________________
gnome-db-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gnome-db-list