On Thu, Jul 21, 2005 at 19:10:03 +1000,
Ezequiel Tolnay <mail@etolnay.com.ar> wrote:
>
> * Stored procedures: Although similar to functions, SP always return an
> execution status rather than a result, but provide the caller with the
> equivalent of running several sql instructions, as if running a script.
> Unlike functions, their results cannot be utilised by most other
> statements, with the exception of INSERT [...] EXECUTE [...]. Their main
> attractive is to simplify the detachment between interface and
> implementation. Perhaps this could be achieved extending some features
> of functions, perhaps enabling a combination of SETOF result (which
> needs an externally defined result type) and OUT parameters (which is
> flexible but restricted to a single row), or handled similarly as the
> current possibility to return cursors.
Postgres' functions are already pretty powerful and cover most of what
stored procedures do. People are working on a version of stored procedures
that is closer to the standard and that should ease conversions. Some of
this is going to be in 8.1. Other stuff is planned for the future. You
can probably get more details by looking through the -hackers archives.
> * Inter-database access: Although PG greatly benefits from the use of
> schemes, many times different applications are required to use separate
> databases but still sharing some resources. The only current facility
> that I'm aware of for this purpose in PG is through pl-perl functions,
> but this prevents reusing current credentials and greatly reduce
> flexibility.
You may want to look at the dblink contrib module. I think it does some
of what you want.
> * Allow to optionally prevent overloading in functions, thus allowing
> the CREATE OR REPLACE command replace the function despite having
> different parameters
What happens if there is more than one existing function with that name
already. Do all of the old functions get deleted?