>
> Further to the discussion regarding the creation of the table. There is the
> Path: /FIELDS_A/@COLUMN_TYPE. Here a complete type must be set. For
> postgresql that is varchar(30) for instance. As mentioned before I would
> like to see this part more provider independent. Perhaps we can reach some
> sort of a compromise. First I tell you what I would like to see:
>
> /FIELDS_A/@COLUMN_GTYPE
> /FIELDS_A/@COLUMN_SIZE
> /FIELDS_A/@COLUMN_SCALE
>
> example values:
> GDA_TYPE_NUMERIC
> 10
> 2
>
> This then will be translated by the postgresql provider for instance to
> numeric(10,2).
>
> To provide both options to the user, we can say that if
> /FIELDS_A/@COLUMN_TYPE (the current situation), this overrules any
> situation. If it is not set, the user should set
>
> /FIELDS_A/@COLUMN_GTYPE
> /FIELDS_A/@COLUMN_SIZE (if applicable)
> /FIELDS_A/@COLUMN_SCALE (if applicable)
>
> Then for the various providers we can make this into something that works
> for the data provider.
>
I agree on having the /FIELDS_A/@COLUMN_SIZE and
/FIELDS_A/@COLUMN_SCALE as this makes things more provider
independant.
However I prefer to stay with a /FIELDS_A/@COLUMN_TYPE because it's
closer to what a user can easily fill-in and it's easy for a
programmer (using gda_server_provider_get_default_dbms_type()) to
convert from a GType to a DBMS type. It also makes it possible to
check and take actions when the provider doesn't support a particular
GType before trying to execute the action.
So I propose to have
/FIELDS_A/@COLUMN_TYPE (required)
/FIELDS_A/@COLUMN_SIZE (optional)
/FIELDS_A/@COLUMN_SCALE (optional)
Is it Ok for you? If so, can you make the modifications in the xml.in
files and in the -ddl.c files for some or all of the providers?
Ok with me, but if you bring back everything to just COLUMN_TYPE (as opposed to also have COLUMN_GTYPE), how would you deal with the situation if a user sets the values as follows: