Tom Lane wrote:
> Because the domain is supposed to be opaque as to exactly what its
> underlying type is. In particular, you're supposed to do this:
>
> CREATE DOMAIN varchar2 AS pg_catalog.varchar(10);
>
> If you look in the SQL spec you will not find any suggestion that it
> should w
Takahiro Itagaki wrote:
> This feature would be useful for migration
> from other DBMSes that have non-standard data types.
Domains can indeed be useful to allow migration -- if they are used
as intended. If you identify all of the unique data domains on your
source platform and define the co
> /* Domains never accept typmods, so no typmodin/typmodout needed */
> but can we relax the restriction? This feature would be useful for migration
> from other DBMSes that have non-standard data types.
For migration, wouldn't it be adequate simply to ignore the typemod? Or
to allow it as p
Takahiro Itagaki writes:
> Domains were created successfully, but I cannot use type modifiers for them.
> =# CREATE TABLE tbl (v varchar2(10));
> ERROR: type modifier is not allowed for type "varchar2"
> What reason do we have not to inherit typmodin/typmodout from the base type?
Becaus
On Wed, Jan 6, 2010 at 1:12 AM, Takahiro Itagaki
wrote:
>
> What reason do we have not to inherit typmodin/typmodout from the base type?
> I found a comment in DefineDomain(),
> /* Domains never accept typmods, so no typmodin/typmodout needed */
> but can we relax the restriction? This feature
Hi,
I'm trying to use DOMAIN as just synonym types for database migration.
For example,
=# CREATE DOMAIN varchar2 AS pg_catalog.varchar;
=# CREATE DOMAIN number AS pg_catalog.numeric;
Domains were created successfully, but I cannot use type modifiers for them.
=# CREATE TABLE tbl (v v
