On Fri, Dec 26, 2008 at 3:57 PM, Grzegorz Jaśkiewicz wrote:
> another glance at source code, and docs tells me - that there's not
> such thing as default value for custom type - unless that type is
> defined as new base scalar type. So probably, that would require
> postgresql to allow users to de
another glance at source code, and docs tells me - that there's not
such thing as default value for custom type - unless that type is
defined as new base scalar type. So probably, that would require
postgresql to allow users to define default values for composite types
as well, like that:
create ty
On Wed, Dec 24, 2008 at 6:41 PM, Erik Jones wrote:
>
> On Dec 24, 2008, at 12:04 PM, Grzegorz Jaśkiewicz wrote:
>
>> On Wed, Dec 24, 2008 at 6:12 PM, Erik Jones wrote:
>>>
>>> Yes, and columns have default values, too, which are not tied to their
>>> datatype's default value (if it even has one).
I hope Tom can hear my prayers. This basically means, I won't be able
to use domains+type in my designs. :/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
gj=# create domain dfoo as varchar(20) default 'bollocks' not null;
CREATE DOMAIN
Time: 1680,908 ms
gj=# create table foo( a bigserial not null, b int default
(random()*100)::int not null );
NOTICE: CREATE TABLE will create implicit sequence "foo_a_seq" for
serial column "foo.a"
CREATE TABLE
Time
On Dec 24, 2008, at 12:04 PM, Grzegorz Jaśkiewicz wrote:
On Wed, Dec 24, 2008 at 6:12 PM, Erik Jones
wrote:
Yes, and columns have default values, too, which are not tied to
their
datatype's default value (if it even has one). ALTER TABLE
initializes rows
to have the new *column's* defaul
On Wed, Dec 24, 2008 at 6:12 PM, Erik Jones wrote:
> Yes, and columns have default values, too, which are not tied to their
> datatype's default value (if it even has one). ALTER TABLE initializes rows
> to have the new *column's* default. A column of some domain type could
> easily have some de
On Dec 22, 2008, at 1:08 PM, Grzegorz Jaśkiewicz wrote:
On Mon, Dec 22, 2008 at 6:10 PM, Erik Jones
wrote:
As mentioned above, by "fixing" the behavior to be what you're
expecting
you'd be breaking the defined behavior of ALTER TABLE.
I don't understand. The domain's have default values,
On Mon, Dec 22, 2008 at 6:10 PM, Erik Jones wrote:
> As mentioned above, by "fixing" the behavior to be what you're expecting
> you'd be breaking the defined behavior of ALTER TABLE.
I don't understand. The domain's have default values, how will it
break alter table ? Please explain.
--
GJ
-
On Dec 22, 2008, at 4:49 AM, Grzegorz Jaśkiewicz wrote:
so, consider this one:
create sequence seq1;
create domain foo1 as bigint default nextval('seq1') not null;
create domain foo2 as timestamp without time zone default now() not
null;
create type footype as
(
a foo1,
b foo2
) ;
create
On Mon, Dec 22, 2008 at 1:49 PM, Grzegorz Jaśkiewicz wrote:
> but that defeats whole purpose of domains, doesn't it ?
>
> well, on top of that - I could create another domain with default
> (nextval, now), but still
Well I can't, it doesn't work :(
create domain xyz as footype default(nextva
so, consider this one:
create sequence seq1;
create domain foo1 as bigint default nextval('seq1') not null;
create domain foo2 as timestamp without time zone default now() not null;
create type footype as
(
a foo1,
b foo2
) ;
create table bar(a bigint not null, b varchar(20));
insert into ba
12 matches
Mail list logo