Re: PL/PgSQL discussion - Mailing list pgsql-hackers

From jwieck@debis.com (Jan Wieck)
Subject Re: PL/PgSQL discussion
Date
Msg-id m0yDYb9-000BFRC@orion.SAPserv.Hamburg.dsh.de
Whole thread Raw
In response to Re: PL/PgSQL discussion  (Hannu Krosing <hannu@trust.ee>)
List pgsql-hackers
Hannu Krosing wrote:
>
> Jan Wieck wrote:
>
> > Hannu Krosing wrote:
> > >
> > > jwieck@debis.com (Jan Wieck) wrote:
> > >
> >
> >     Hmmm  -  how  does  a language handler then notice that a new
> >     session began?
>
> Probably by defining the reset_session or init_session functions for the language handler and
> calling it at the connect time.

    Not in the current implementation of the backend/pl_handler
    interface. But a global variable SessionId might help.

> > > Then we would not need the END IF, END LOOP etc.
> >
> >     The LOOP ... END LOOP etc. syntax  is  just  what  I  saw  in
> >     Oracles   PL/SQL   documentation.  I  could  also  live  with
> >     BEGIN...END, but what is it good for to be different?
>
> then again we don't need the block delimiters ;)

    Forgotten  in  the  1st  draft.  Variables are initialized to
    their default values every time a block/subblock is  entered.
    Not only when the function is entered.

      ...
      FOR i IN 1..10 LOOP
        DECLARE
          flag bool DEFAULT false;
          n integer DEFAULT 0;
        BEGIN
        ...
        END;
      END LOOP;
      ...

> >         Create   a  new  catalog  pg_parameter,  that  holds  the
> >         parameter names  and  other  information  (like  notnull,
> >         atttypmod etc.). So a function can be defined to expect a
> >         VARCHAR(20) NOT NULL.
>
> This again can be done by automatically rewriting these to additional statements to check for
> this as first things in the function body. It makes only a theoretical difference if the error
> is reportid before the call or just after it.

    But this rewriting must be done when the function is created.
    At this time, the pl_handler and it's parser  aren't  called.
    It  is  done  by  the  backends  main  parser.  For  loadable
    procedural languages, the main parser doesn't  know  anything
    about the languages syntax or if the string given after AS is
    a program text at all. It only creates the pg_proc tuple.

>
> >     Currently  only  'null'  and  'single  value'.  The  executor
> >     doesn't  accept anything else for non-sql language functions.
> >     PL functions are treated by the executor like 'C'  functions.
>
> Actually what I understood from the docs was thatit is 'terribly complicated' and 'beyond the
> scope of this tutorial', but not impossible ;)

    I  tried  that  really  hard  with  no  luck.  And   I   know
    ExecMakeFunctionResult()   pretty  good.  But  I'll  give  it
    another shot when PL/pgSQL reached a  state  where  it  makes
    sense.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck@debis.com (Jan Wieck) #

pgsql-hackers by date:

Previous
From: jwieck@debis.com (Jan Wieck)
Date:
Subject: Re: [HACKERS] suspected problem with cache updates
Next
From: darrenk@insightdist.com (Darren King)
Date:
Subject: Re: [HACKERS] suspected problem with cache updates