| Subject | Re: [firebird-support] followup to 'execute function' |
|---|---|
| Author | Helen Borrie |
| Post date | 2004-06-06T23:44:49Z |
At 11:05 PM 6/06/2004 +0000, you wrote:
function: designed to take constants as inputs and return a result.
Functions operate on values, procedures operate on objects.
Actually, you can sometimes satisfy a need for a function by writing a
stored procedure: that is, it is not a requirement for a procedure to
query the database. The reverse is not true: you must never write a
function that has to query the database.
Things are getting more blurred these days: RDBMS engines, esp. the
object-relational ones, are acquiring the ability to let you define
internal objects with their own functionality using a specialised JVM
that's part of the engine. There's been discussion from time to time in
firebird-architect about doing something like this with Firebird, via a
plug-in - so don't give up hope!
/heLen
>I just looked into rfunc2 source code, and they seem to use theHmm, a function is a function, not a procedure! It's just like any SQL
>following idiom:
>
> select func(...) from RDB$DATABASE;
>
>I guess I missed this in the docs.
>
>I still think 'execute function' support would be nice syntactical
>sugar.
function: designed to take constants as inputs and return a result.
Functions operate on values, procedures operate on objects.
Actually, you can sometimes satisfy a need for a function by writing a
stored procedure: that is, it is not a requirement for a procedure to
query the database. The reverse is not true: you must never write a
function that has to query the database.
Things are getting more blurred these days: RDBMS engines, esp. the
object-relational ones, are acquiring the ability to let you define
internal objects with their own functionality using a specialised JVM
that's part of the engine. There's been discussion from time to time in
firebird-architect about doing something like this with Firebird, via a
plug-in - so don't give up hope!
/heLen