Subject Re: Domains and Why they wont work for I/O params in stored procs.
Author Alexei Isac
Thanks Helen,

Makes sense now.

What is the reccomended way to define datatypes for the IN an OUT
parameters in scripts ? My script is getting a little too big and I
was wondering if there is an alternate way to define the VARCHAR(N)
once for the various IN params in PSQL scrpits, that way if the
lengths need to be increased, I need to do it only in one place.

regards
-Alexei

ps: Btw, excellent work on the book, I love it. Got me upto speed very
quick. If I may say so, In the next edition, I would like to see a
little more on the new embedded server, which I think is a killer
compared to Sqlite and Berkley DB.

--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@t...>
wrote:
> At 11:01 PM 1/03/2005 +0000, you wrote:
>
>
> >I am a new FB user and I am not able to use defined domains in the
> >IN/OUT params of stored procs.
>
> True.
>
>
> >Are there any plans to change this behaviour ?
>
> No, not soon.
>
> >The way I thought about
> >the usage for Domains, is you define a type (and behaviour) once and
> >refer to it in other places(just like #define in C/C++). That way you
> >only need to change it in one place if the defenition changes.
> >
> >Anyone have any idea on why it was done this way ?
>
> A domain is not a data type, it is a packaged column definition.
One of
> the (many) ways it differs from a data type is that it can be
> changed. When a domain definition is changed, the changes are
propagated
> to all of the column definitions that use them.
>
> A PSQL module is a compiled object, not a definition - hence, domain
> changes could not be propagated to a PSQL module without a huge
amount of
> (currently unsupported) conflict resolution and subsystem activity
in the
> database.
>
> ./heLen