Domain-based procedure parameters and default values

17 views
Skip to first unread message

Dimitry Sibiryakov

unread,
Feb 27, 2026, 4:54:56 PMFeb 27
to firebir...@googlegroups.com
Hello All,

in the code of jrd_prc::scan() I see that default value for procedure
parameter can be read either from RDB$PROCEDURE_PARAMETERS or from RDB$FIELDS,
but no matter how I tried, it is always stored in RDB$PROCEDURE_PARAMETERS.

Question 1: how to get default value for procedure parameter to be stored in
RDB$FIELDS?
Question 2: shouldn't procedure parameters implicitly inherit default value
from domain or field they are based on?

--
WBR, SD.

Mark Rotteveel

unread,
Feb 28, 2026, 3:32:29 AMFeb 28
to firebir...@googlegroups.com
On 27/02/2026 22:54, 'Dimitry Sibiryakov' via firebird-devel wrote:
>   Hello All,
>
>   in the code of jrd_prc::scan() I see that default value for procedure
> parameter can be read either from RDB$PROCEDURE_PARAMETERS or from
> RDB$FIELDS, but no matter how I tried, it is always stored in
> RDB$PROCEDURE_PARAMETERS.
>
>   Question 1: how to get default value for procedure parameter to be
> stored in RDB$FIELDS?


The default of a parameter should never be stored in RDB$FIELDS. It is
where the default of a domain is stored.

>   Question 2: shouldn't procedure parameters implicitly inherit default
> value from domain or field they are based on?


Maybe I'm missing something, but isn't that _why_ it *reads* from
RDB$FIELDS?

Mark
--
Mark Rotteveel

Dimitry Sibiryakov

unread,
Feb 28, 2026, 4:31:55 AMFeb 28
to firebir...@googlegroups.com
'Mark Rotteveel' via firebird-devel wrote 28.02.2026 9:32:
>>
>>    Question 1: how to get default value for procedure parameter to be stored
>> in RDB$FIELDS?
>
>
> The default of a parameter should never be stored in RDB$FIELDS. It is where the
> default of a domain is stored.

Yes, but if parameter is declared with type only, RDB$XXX domain is created
for it automatically because RDB$PROCEDURE_PARAMETERS has no capacity to keep a
data type.

>>    Question 2: shouldn't procedure parameters implicitly inherit default value
>> from domain or field they are based on?
>
> Maybe I'm missing something, but isn't that _why_ it *reads* from RDB$FIELDS?

Yes, it looks so from code, but following script fails:

create domain t_dom_default varchar(20) default 'Domain default';
create procedure t_proc (a varchar(20) default 'Parameter default', b
t_dom_default) as begin end;

That's the question.

--
WBR, SD.

Mark Rotteveel

unread,
Feb 28, 2026, 4:49:05 AMFeb 28
to firebir...@googlegroups.com
On 28/02/2026 10:31, 'Dimitry Sibiryakov' via firebird-devel wrote:
> 'Mark Rotteveel' via firebird-devel wrote 28.02.2026 9:32:
>>>
>>>    Question 1: how to get default value for procedure parameter to be
>>> stored in RDB$FIELDS?
>>
>>
>> The default of a parameter should never be stored in RDB$FIELDS. It is
>> where the default of a domain is stored.
>
>   Yes, but if parameter is declared with type only, RDB$XXX domain is
> created for it automatically because RDB$PROCEDURE_PARAMETERS has no
> capacity to keep a data type.

When defining a column or parameter with an explicit default, it's never
stored in RDB$FIELDS.

>>>    Question 2: shouldn't procedure parameters implicitly inherit
>>> default value from domain or field they are based on?
>>
>> Maybe I'm missing something, but isn't that _why_ it *reads* from
>> RDB$FIELDS?
>
>   Yes, it looks so from code, but following script fails:
>
> create domain t_dom_default varchar(20) default 'Domain default';
> create procedure t_proc (a varchar(20) default 'Parameter default', b
> t_dom_default) as begin end;
>
>   That's the question.

I think this might indicate that the change of
https://github.com/FirebirdSQL/firebird/issues/7566 (which I just
happened to look at today) is not complete, because before that, the
default was never obtained from the domain for procedures or functions,
only the one explicitly specified.

To be honest, I'm not even sure if the change mentioned in the comments
to use the domain default also applies for implicit defaults, or only
when passing explicit DEFAULT when calling the stored procedure or function.

Mark

PS It would be helpful to quote the error message when saying something
failed, in this case, the error is "can not define a not null column
with NULL as default value; invalid clause --- 'defaults must be last'"
--
Mark Rotteveel

Dimitry Sibiryakov

unread,
Feb 28, 2026, 5:27:29 AMFeb 28
to firebir...@googlegroups.com
'Mark Rotteveel' via firebird-devel wrote 28.02.2026 10:49:
> When defining a column or parameter with an explicit default, it's never stored
> in RDB$FIELDS.

Exactly that made me wonder if the code in the engine that reads the default
from RDB$FIELDS has any meaning (let alone if it is working as intended).

--
WBR, SD.

Mark Rotteveel

unread,
Feb 28, 2026, 6:01:21 AMFeb 28
to firebir...@googlegroups.com
It should, as it should be used when you use DEFAULT in the argument list.

Mark
--
Mark Rotteveel

Dimitry Sibiryakov

unread,
Feb 28, 2026, 6:04:13 AMFeb 28
to firebir...@googlegroups.com
'Mark Rotteveel' via firebird-devel wrote 28.02.2026 12:01:
>>    Exactly that made me wonder if the code in the engine that reads the
>> default from RDB$FIELDS has any meaning (let alone if it is working as intended).
> It should, as it should be used when you use DEFAULT in the argument list.

No, DEFAULT in the argument list is implemented in completely different
manner and doesn't use defaults loaded in jrd_prc::scan().

--
WBR, SD.
Reply all
Reply to author
Forward
0 new messages