Re: [SQL] PL/PGSQL function with parameters

Josh Berkus wrote:
> Tom, Jan, Michael,
>
> > While I have not looked closely, I seem to recall that plpgsql handles
> > INTO by stripping that clause out of the statement before it's passed to
> > the SQL engine. Evidently that's not happening in the EXECUTE case.
> >
> > Jan, do you agree this is a bug? Is it reasonable to try to repair it
> > for 7.1? If we do not change the behavior of EXECUTE now, I fear it
> > will be too late --- some people will come to depend on the existing
> > behavior.
>
> If you think that's the best way. What we're really all wanting is a wy
> in PL/pgSQL to pass a parameter as an object name. Doing it *without*
> using EXECUTE would be even better than modifying EXECUTE to accomdate
> SELECT ... INTO variable.
>
> If we can write queries that address tables by OID, that would give us a
> quick workaround ... get the OID from pg_class, then pass it to the
> query as variables of type OID:
>
> SELECT column1_oid, column2_oid FROM table_oid
> WHERE column2_oid = variable1
> ORDER BY column1_oid;
>
> OF course, having PL/pgSQL do this automatically would be even better,
> but I suspect would require a *lot* of extra programming by Jan.

Couple of problems here:

1. The main parser, which is used in turn by the SPI stuff,
doesn't allow parameters passed in for object-
identifiers.

2. I'm not sure if *all* statements are really supported by
SPI_prepare() plus SPI_execp(). EXECUTE currently uses
SPI_exec() to directly invoke the querystring.

3. PL/pgSQL needs a clean way to identify statements that
shall not be cached. First things that come to mind are
- statements using temporary objects
- statements invoking utility commands (or generally
any DDL)
- statements having parameters for object-identifiers

If identified as such non-cacheable query, PL/pgSQL
doesn't use SPI_saveplan() but recreates a new plan every
time.

4. PL handlers in general should have a registering
mechanism for a callback function. On any schema change
(i.e. shared syscache invalidation) this function is
called, causing the PL handler to invalidate *ALL*
function bytecodes and cached plans. Keeping track of
things like "var table.att%TYPE" used in a function would
be a mess - so better throw away anything.

Yes, that's a *lot* to do.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com