Subject | Re: [Firebird-Architect] Extended field/domain DEFAULT usage |
---|---|
Author | Martijn Tonies |
Post date | 2006-01-05T07:37:58Z |
Dmitry,
udfs
generators
procedure headers (without body)
domains (without check constraints)
tables
views
primary key constraints
unique constraints
foreign key constraints
check constraints
procedure bodies
domain check constraints
Database Workbench - tool for InterBase, Firebird, MySQL, Oracle & MS SQL
Server
Upscene Productions
http://www.upscene.com
Database development questions? Check the forum!
http://www.databasedevelopmentforum.com
> > Any, returning to the original topic, I don't see any problems withIf the order is the problem, may I suggest this order:
> > support UDFs in default value clauses for domains. Do you?
>
> What about "DEFAULT MY_UDF((SELECT VAL FROM MY_PROC), GEN_ID(MY_GEN, 1))"
> and alike? :-)
>
> My position is that we must ensure such databases are restorable first.
udfs
generators
procedure headers (without body)
domains (without check constraints)
tables
views
primary key constraints
unique constraints
foreign key constraints
check constraints
procedure bodies
domain check constraints
> > I'm already getting pressure to check the changeMartijn Tonies
> > in Vulcan. Any comments?
>
> I'd rather prefer to see Vulcan Beta released. But given that the changes
> are very local and if the feature requesters are keen to either accept
> constants/parameters only in DEFAULT UDFs or recover from unrestorable
> backups, I have no objections.
Database Workbench - tool for InterBase, Firebird, MySQL, Oracle & MS SQL
Server
Upscene Productions
http://www.upscene.com
Database development questions? Check the forum!
http://www.databasedevelopmentforum.com