Hi,

> Compatibility is a problem. First of all, lots of people use SUSPEND
> at the end of executable procedures just to be safe (unfortunately,
> I still see such advices in some support forums). Secondly, some
> people (me included) use such tricks to emulate stored functions -
> adding SUSPEND to a singleton procedure allows it to be executed
> either via EXECUTE inside PSQL, or via SELECT inside some query.
> Something like GET_CURRENT_SESSION is an obvious example - it can be
> used in the WHERE clause and/or select list as well as somewhere
> inside PSQL (without need to SELECT from this procedure there).

Ok, point taken. I will remove this requirement from the paper.

> FWIW, we have a standard. If we're going to follow it, an ability to
> have both real stored functions and procedures that can be called as
> functions looks very confusing to me. Even if this is easier to
> implement.

Ok. Unfortunately I have no idea about how stored functions should
look like (and as far as I know SQL standard is not available for
free) and cannot cover this issue in the paper. Do you have some
paper/link where I can read more?

Roman