Subject | Re: [firebird-support] Re: followup to 'execute function' |
---|---|
Author | Martijn Tonies |
Post date | 2004-06-07T18:47:24Z |
Hi Craig,
that's why we usually use RDB$DATABASE to test our stuff as
this table contains only a single row and will therefor return a single
row resultset.
With regards,
Martijn Tonies
Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL
Server.
Upscene Productions
http://www.upscene.com
> > >I just looked into rfunc2 source code, and they seem to use theEven more, UDFs are actually "External Functions" - not stored.
> > >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.
> >
> > Hmm, a function is a function, not a procedure! It's just like
> any SQL
> > 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!
>
> Hmm; sorry, the distinction between stored procs and UDF's is still
> a bit fuzzy in some ways. I understand from reading the InterBase
> docs that UDF's should be very short, simple functions so they won't
> tie up the database, esp. in the multi-threaded server (and, as you
> said, they shouldn't query the database - and they certainly
> shouldn't modify it as that may leave the database in an
> inconsistent state. IIRC).
>
> So, that's pretty distinctive. ;-)
> But is there anything wrong with creating a simple UDF that returnsFirebird always needs a FROM clause in a SELECT statement -
> a value, like this:
>
> isql> select generate_guid_udf();
>
> Rather than having this weird syntax (I guess that's where I'm
> confused - why is this necessary? Is this even the proper idiom? I
> just grabbed it and started using it because it worked)
>
> isql> select generate_guid_udf() from RDB$DATABASE;
that's why we usually use RDB$DATABASE to test our stuff as
this table contains only a single row and will therefor return a single
row resultset.
With regards,
Martijn Tonies
Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL
Server.
Upscene Productions
http://www.upscene.com