Subject | Re: [Firebird-Architect] Extended field/domain DEFAULT usage |
---|---|
Author | Jim Starkey |
Post date | 2006-01-04T01:11:25Z |
Thomas Steinmaurer wrote:
original GDML did. The initial value is stored in the field
RDB$DEFAULT_VALUE in RDB$FIELDS, which is defined as a BLR field. The
problem is in the SQL DDL.
I have no doubt that the SQL theorists will object, but in fact it takes
exactly two lines in parse.y to implement what you ask:
default_value : constant
| current_user
| current_role
| internal_info
| null_value
| datetime_value_expression
/* | '(' begin_trigger value end_trigger ')'
{ $$ = $3; }
*/ ;
(In fact, the constant, null value, and datetime_value_expression could
be dropped for a net line loss of one).
[Non-text portions of this message have been removed]
>Hello,Interesting question. The engine is designed to support this, and the
>
>is there anything on the plan/roadmap for an extended usage of the
>field/domain DEFAULT usage?
>
>It would be pretty neat being able to have something like that:
>
>CREATE DOMAIN D_ACTYEAR AS
> INTEGER
> DEFAULT (EXTRACT(YEAR FROM CURRENT_DATE))
>;
>
>Basically, I'm asking for support of built-in functions and UDFs in the
>DEFAULT clause.
>
>Would this be possible or is that already planned?
>
>
>
original GDML did. The initial value is stored in the field
RDB$DEFAULT_VALUE in RDB$FIELDS, which is defined as a BLR field. The
problem is in the SQL DDL.
I have no doubt that the SQL theorists will object, but in fact it takes
exactly two lines in parse.y to implement what you ask:
default_value : constant
| current_user
| current_role
| internal_info
| null_value
| datetime_value_expression
/* | '(' begin_trigger value end_trigger ')'
{ $$ = $3; }
*/ ;
(In fact, the constant, null value, and datetime_value_expression could
be dropped for a net line loss of one).
[Non-text portions of this message have been removed]