Subject | Re: [Firebird-Architect] Exec. statement parameters |
---|---|
Author | Nando Dessena |
Post date | 2007-12-14T13:40:58Z |
Adriano,
A> "set"?
"Set" assigns a value to a column. "Bind" binds a value to a name. Here's
what I mean: This is an assignment:
update table set column = 2
This is a binding:
select 3 as somename from table
A> AFAIU, "bind" means something, as an OUT parameter, where value assigned
A> to the parameter is assigned back to the caller variable.
No, I don't mean this. I mean "to bind" as "to attach", "to tie", "to
link".
A> And as UPDATE...SET sets the value of table columns, SET in call sets
A> the values of the calling procedure parameters.
While this might have a sense at the implementation level, people are
not used to think that passing a value to a procedure as an argument
[you see? I can't refrain from using AS for this even in common
english :-)] is an assignment (although it certainly is in the end).
In common jargon, when you call a procedure you are binding actual
values to the formal arguments:
create procedure p (x int) as ...
Here x is a formal argument.
execute procedure p (3)
Here 3 is an actual argument, bound to the formal argument x. The bond
is reflected by the fact that, inside the procedure code, reading the
formal argument x yields the actual argument 3.
From the above descends that when you want to make the bond explicit
(as opposed to implicit as in the code above) you use an operator that
is already used for binding in other cases:
execute procedure p (3 as x)
Looks very straightforward to me.
Please note that if you want to pursue the assignment paradigm
instead, then you should use
execute procedure p (set x = 3)
which IMHO:
a) is inconsistent, because that is the way to do assignments in SQL,
not PSQL. In PSQL you'd just do x = 3.
b) is wordy
c) is counter-intuitive
Using the correct assignment operator
execute procedure p (x = 3)
leaves you with the ambiguities you have described, and you are forced
to find a different operator to escape from them. But the root cause
is, IMHO, that assignment is not the correct paradigm here. Binding
is.
Hope I have made my point clear.
--
Nando Dessena
>> It's not consistent semantically. SET does assignment, whereas whatA> Could you describe what exactly is "bind" and how different it is from
>> you are after is binding.
A> "set"?
"Set" assigns a value to a column. "Bind" binds a value to a name. Here's
what I mean: This is an assignment:
update table set column = 2
This is a binding:
select 3 as somename from table
A> AFAIU, "bind" means something, as an OUT parameter, where value assigned
A> to the parameter is assigned back to the caller variable.
No, I don't mean this. I mean "to bind" as "to attach", "to tie", "to
link".
A> And as UPDATE...SET sets the value of table columns, SET in call sets
A> the values of the calling procedure parameters.
While this might have a sense at the implementation level, people are
not used to think that passing a value to a procedure as an argument
[you see? I can't refrain from using AS for this even in common
english :-)] is an assignment (although it certainly is in the end).
In common jargon, when you call a procedure you are binding actual
values to the formal arguments:
create procedure p (x int) as ...
Here x is a formal argument.
execute procedure p (3)
Here 3 is an actual argument, bound to the formal argument x. The bond
is reflected by the fact that, inside the procedure code, reading the
formal argument x yields the actual argument 3.
From the above descends that when you want to make the bond explicit
(as opposed to implicit as in the code above) you use an operator that
is already used for binding in other cases:
execute procedure p (3 as x)
Looks very straightforward to me.
Please note that if you want to pursue the assignment paradigm
instead, then you should use
execute procedure p (set x = 3)
which IMHO:
a) is inconsistent, because that is the way to do assignments in SQL,
not PSQL. In PSQL you'd just do x = 3.
b) is wordy
c) is counter-intuitive
Using the correct assignment operator
execute procedure p (x = 3)
leaves you with the ambiguities you have described, and you are forced
to find a different operator to escape from them. But the root cause
is, IMHO, that assignment is not the correct paradigm here. Binding
is.
Hope I have made my point clear.
--
Nando Dessena