Subject RE: [IB-Architect] Database names
Author David Schnepper
I also need to point out that there is a difference between a "Native SQL"
function and a UDF. Native SQL functions can more easily deal with multiple
datatypes and proper results. For instance, take a function ADD(a,b)

ADD(integer,float) -> float
ADD(float,integer) -> float
ADD(integer,int64) -> int64
ADD(date,time) -> Timestamp
ADD(numeric(9,2),numeric(9,3)) -> numeric(10,3)

(etc). The SQL parser can figure this out when the function is "native
SQL"
- but it becomes hairy when "ADD" is implemented as a UDF.

More real examples: SQL Coalease(), Oracle to_char(), SQL UPPER() & LOWER()

eg: UPPER(f) --> same character set as f, and same collation as f
UPPER('f') --> Same character set, default collation

Dave

-----Original Message-----
From: Bill Karwin [mailto:bill@...]
Sent: Thursday, May 04, 2000 7:23 PM
To: IB-Architect@egroups.com
Subject: Re: [IB-Architect] Database names


> Actually there are plenty of functions already natively included in
> Interbase.

Most of these are provided as UDFs and currently require declaration in each
database that uses the functions. Truly native functions that are
recognized by the SQL parser and do not require external libraries are
another discussion...

> I believe the sugestion Bill is making is not to remove the capacity to do
> this on a database by database basis but to ADD the capacity to define
them
> on a system wide level. Almost like inheritance.

That is what I'm suggesting, but I wouldn't call it inheritance. It's
merely like having an "INI" file that declares certain functions by default
each time you create a new database.

Currently, one could use "input functions.sql" in the isql tool right after
you create a database. Perhaps the idea that I have is better handled in
the isql tool than in the server. It could really be thought of as a
database design issue, not a runtime issue.

I'll build this capability into my "pisql.pl" and see how people like it.
:-)

> In fact I would like to see
> a capacity to group these function definitions into functional units and
> then assign them to the system or a particular database depending on its
> purpose. For example a financial reporting database might be allocated a
set
> of functions for handling quarters etc.

With the "input functions.sql" method, you could for instance group subsets
of function declarations each into a separate file, e.g.
"financefunctions.sql". This works with today's version of InterBase just
fine.

Bill Karwin


------------------------------------------------------------------------
Would you like to save big on your phone bill -- and keep on saving
more each month? Join beMANY! Our huge buying group gives you Long Distance
rates which fall monthly, plus an extra $60 in FREE calls!
http://click.egroups.com/1/2567/3/_/830676/_/957493273/
------------------------------------------------------------------------

To unsubscribe from this group, send an email to:
IB-Architect-unsubscribe@onelist.com