From a discussion on the gnome-db mailing list regarding this query issued by the PostgreSQL provider:
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';

Vivien Malerba posted this:
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...

Mark Johnson:
> 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.
> >>     
>
> I believe the information is in the existence of a row returned or no.
>   
The c2.contype='P' test checks if the column is a primary key.  This 
alternates with checking the columns for a unique key ('u').  However, 
the query is returning zero rows regardless of the presence or absence 
of a primary or unique key.  In the above instance, the column is a 
primary key as shown by the \d+ command.  When I tried columns that are 
not primary keys, they return the same results.  I believe, therefore, 
that there is a problem with this query.

I have found the problem.  The PostgreSQL manual (version 8.2.6; section 43.13 pg_constraint) lists the meaning of values in the contype column.  However, it shows a lower-case 'p' for primary key.

Here is a sample run from psql on the gnucash db backend database:
gnucash_qif_db=# select conname, contype, conkey[1] from pg_catalog.pg_constraint where contype='p';
        conname        | contype | conkey
-----------------------+---------+--------
 customers_pkey        | p       |      1
 jobs_pkey             | p       |      1
 transactions_pkey     | p       |      1
 splits_pkey           | p       |      1
 lots_pkey             | p       |      1
 budgets_pkey          | p       |      1
 taxtables_pkey        | p       |      1
 taxtable_entries_pkey | p       |      1
 recurrences_pkey      | p       |      1
 employees_pkey        | p       |      1
 orders_pkey           | p       |      1
 commodities_pkey      | p       |      1
 accounts_pkey         | p       |      1
 slots_pkey            | p       |      1
 schedxactions_pkey    | p       |      1
 invoices_pkey         | p       |      1
 prices_pkey           | p       |      1
 entries_pkey          | p       |      1
 vendors_pkey          | p       |      1
 books_pkey            | p       |      1
 billterms_pkey        | p       |      1
(21 rows)

gnucash_qif_db=# select 1 from pg_catalog.pg_class c, pg_catalog.pg_constraint c2, pg_catalog.pg_attribute a
gnucash_qif_db-# 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)

gnucash_qif_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?
----------
        1
(1 row)

Note that the only difference between the two queries is the latter uses a lower-case 'p'.  It successfully detects the primary key on that column.

I'm not sure what the functional implications of this are.  I found the query by logging what the PostgreSQL provider sends to the db, and these queries are very common.  I checked into what it was looking for.