johnf wrote:
> 
> Using
>  CREATE DOMAIN unsigned_smallint AS SMALLINT  CHECK(VALUE >= 0);
> 
> dbPostgres.py getFields() would find "unsigned_smallint" as the data type and 
> by chance would be correct in applying it to the correct Dabo data type.  Of 
> course if the user defined data type that had not contained the "int" in the 
> name or anything of the other standard data types names dbPostgres would have 
> returned 'fldType = "?"" for a field data type.  
> 
> It maybe possible to check the pg_type table and determine the actual data 
> type by checking the "typbasetype" field.  If the "typbasetype "is not" 0 
> then it is a pointer (oid) into the pg_type which returns the basic postgres 
> data type.  This also appears to allow recursive assignments.  IOW the first 
> user defined data type can point to a user data ... etc.
> 
> Something like below.
> 
> fldType = findRealDataType(r["typname"])
> if "int" in fldType:
>       fldType = "I"
> ...
> else:
>     fldType = "?"
>    
> 
> 
> But in the case of 
> CREATE TYPE cris_uint_type AS  unsigned_integer;
> 
> I don't see how our current way of Dabo data type assignments would work.
> 
> The first form of CREATE TYPE creates a composite type. The composite type is 
> specified by a list of attribute names and data types.  Sort of like 
> the "array" data type we are not supporting currently.
> 
> And in the second form of "CREATE TYPE" the use of input and output functions 
> is required.  But the data type is defined and should resolve to one of 
> Postgres basic data types for the output function.  However, the data type of 
> the input function could be any of the allowed Postgres data types (including 
> user defined types).  Although, it (input function) normally accepts a 
> string, it means I will not know what the input function requires as a data 
> type (without some sort of hard coding or reading the input function).  
> 
> I think it would require some major coding of the framework to allow data 
> types created with "CREATE TYPE" to work with DataFields and other parts of 
> the framework.
> 
> Anybody have any different thoughts?
> 

As long as there is no way to get a basetype this turns out to be so
database specific that i don't think it would belong into Dabo.

Uwe



_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message: http://leafe.com/archives/byMID/dabo-users/[EMAIL PROTECTED]

Reply via email to