Re: PL/PgSQL discussion

From: jwieck(at)debis(dot)com (Jan Wieck)
To: hannu(at)trust(dot)ee (Hannu Krosing)
Cc: jwieck(at)debis(dot)com, hannu(at)trust(dot)ee, pgsql-hackers(at)hub(dot)org
Subject: Re: PL/PgSQL discussion
Date: 1998-03-13 17:50:23
Message-ID: m0yDYb9-000BFRC@orion.SAPserv.Hamburg.dsh.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hannu Krosing wrote:
>
> Jan Wieck wrote:
>
> > Hannu Krosing wrote:
> > >
> > > jwieck(at)debis(dot)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(at)debis(dot)com (Jan Wieck) #

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message sferac 1998-03-13 17:57:33 Re: [HACKERS] casting & type comments
Previous Message Darren King 1998-03-13 17:39:24 Re: [HACKERS] suspected problem with cache updates