Thomas Lockhart wrote:
> postgres=> create table x (i smallint);
> CREATE
> postgres=> create table y (j bigint);
> ERROR: Unable to locate type name 'bigint' in catalog
so BIGINT (as a synonym for INT8 is not supported). Is
BIGINT not a standard SQL92 or de Facto?
BTW: I have tried to make BIGINT a synonym of INT8 using
CREATE TYPE with the parameters I've got from pg_type
but it would not work.
> afaik we support the type names defined in SQL92 (like smallint),
> historical names in Postgres, and some extensions. What more do we
> need?
I'm not entirely sure which types in pg_type are historical
but unsupported and which do work. For example: what is
"bytea" ... I remember darkly that this was an array of bytes
in original Postgres? But I may be mistaken. Why do I ask?
Because I see the need to store small byte sequences w/o
having to deploy the large object inversion. For example
if I want to store 128 bit UUIDs (or something similar with
128 bits) I need this as a straight byte sequence, indexable
of course -- not as a CHAR (since no character conversion should
occur and these bytes are not printable), not as a BLOB.
Then, how much do we guarrantee about PostgreSQL internal OIDs?
What if I want to use OIDs directly in the context of a multiple
data bases. Is there any way to control assignment of OIDs so
that cooperation with other databases would be possible?
thanks,
-Gunther
My original question was:
> > A related question is whether we could support some more
> > standard names for data types (e.g., BIGINT, SMALLINT, etc.)
> > But I'm not sure there is really any standard. I would be
> > willing to work a little on these data types but I'd need
> > someone to hint me on who else is doing stuff and, if possible,
> > where to look first (and what known mistakes to avoid.)
--
Gunther_Schadow-------------------------------http://aurora.rg.iupui.edu
Regenstrief Institute for Health Care
1050 Wishard Blvd., Indianapolis IN 46202, Phone: (317) 630 7960
schadow@aurora.rg.iupui.edu------------------#include <usual/disclaimer>