Subject | Re: [Firebird-Architect] Fb 2.1 and TYPE OF in PSQL |
---|---|
Author | Adriano dos Santos Fernandes |
Post date | 2006-11-20T14:25:51Z |
Martijn Tonies wrote:
RDB$PROCEDURE_PARAMETERS.
RDB$NULL_FLAG was even added, but commented in the code.
I didn't added yet because we currently don't use it, I'm not sure if it
should be added now or when more than one type exists.
Adriano
> Hi,I've this in my plan, add RDB$PARAMETER_MECHANISM and RDB$NULL_FLAG to
>
> I kinda raised this issue at the Firebird Conference allready, for those of
> you
> who weren't there or didn't care ;) ... Here's it again.
>
> Firebird 2.1 has a new TYPE OF functionality that will allow to use the
> datatype of a domain in Stored Procedure parameters and declared
> variables in Procedures & Triggers. These "dependencies" will be tracked
> as well. After modifying a datatype of a domain, a recompile of the
> procedure would then recreate the procedure with the new datatypes.
>
> To be able to create proper DDL statements, tools needs to know if
> a domain was used as a source for the parameter datatype. The idea was
> to use RDB$FIELD_SOURCE in RDB$PROCEDURE_PARAMETERS.
>
> I have to objections against this, or perhaps just 1, depending on how you
> look at it.
>
> 1) the parameter doesn't "use" the domain in full, only the datatype. So
> that
> means no check constraint, no NULL flag, so this would be invalid usuage
> of that column.
>
> 2) if Firebird every allows full use of domains, there's no way to
> distinguish
> between "TYPE OF" or a real domain.
>
>
> Now, if you still decide on using RDB$FIELD_SOURCE, fine by me. But
> I would like to add a (minor?) ODS change then: a flag in PROC_PARAMS
> that tells us tool developers that this is a "TYPE OF" construct and not a
> real domain. This way, if a future version of Fb allows domains, the value
> of field_source is always correct and will not change between versions
> (namely:
> type of versus real domain) when the flag is being added in a later version.
>
RDB$PROCEDURE_PARAMETERS.
RDB$NULL_FLAG was even added, but commented in the code.
I didn't added yet because we currently don't use it, I'm not sure if it
should be added now or when more than one type exists.
Adriano