Hmm, your using ColdFusion, so that goes through the ODBC driver, which
picks up the 'primary key' by looking for an index named 'foo_pkey',
I think. Ah, here it is:
in interfaces/odbc/info.c:
sprintf(tables_query, "select ta.attname, ia.attnum"
" from pg_attribute ta, pg_attribute ia, pg_class c, pg_index i"
" where c.relname = '%s_pkey'"
" AND c.oid = i.indexrelid"
" AND ia.attrelid = i.indexrelid"
" AND ta.attrelid = i.indrelid"
" AND ta.attnum = i.indkey[ia.attnum-1]"
" order by ia.attnum", pktab);
So, don't name the primary key constraint, or name it 'something_pkey'
and you should be fine. Something's falling back to trying to use
oid if it can't find a primary key: I'm note sure if that's inside the
ODBC driver, or in ColdFusion.
Hmm, seems we have other Access specific hacks in the ODBC driver:
/*
* I have to hide the table owner from Access, otherwise it
* insists on referring to the table as 'owner.table'. (this
* is valid according to the ODBC SQL grammar, but Postgres
* won't support it.)
*
* set_tuplefield_string(&row->tuple[1], table_owner);
*/
I bet PgAdmin would like to have that info.
Ross
On Tue, Jun 19, 2001 at 06:11:12PM -0400, P. Dwayne Miller wrote:
> My bad on the syntax of all three. I used your syntax (which is what I had
>originally used) and
> got the same results with the \d command that you show.
>
> I'm only using Cold Fusion to read data from the resulting table, not create the
>table... and I
> still get an error when I have created the primary key using the table constraint
>syntax. Cold
> Fusion is reporting that the primary key has been defined for the column oid. Using
>the correct
> syntax with the first two CREATE TABLE statements, Cold Fusion reports the primary
>key field as
> msgid.
>
> Thanks for your reply,
> Dwayne
>
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl