Re: [HACKERS] PL/pgSQL - for discussion

From: jwieck(at)debis(dot)com (Jan Wieck)
To: ocie(at)paracel(dot)com
Cc: jwieck(at)debis(dot)com, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] PL/pgSQL - for discussion
Date: 1998-03-13 08:59:36
Message-ID: m0yDQJU-000BFRC@orion.SAPserv.Hamburg.dsh.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Ocie wrote:
>
> This looks good.
>
> I especially like the "for x in select ..." part, it looks a lot more
> elegant than cursors, but we might want to provide a cursor with a
> "get next row" and "get previous row" function, as the for loop only
> goes one way.

We don't have real cursors up to now. The SPI_exec() and
SPI_execp() functions return the complete set of tuples
selected. And I'm not sure if that what PostgreSQL calls a
cursor can be used in the backend over SPI. It requires named
portals and them in turn require a transaction block (BEGIN
... COMMIT). But I think it would be easy to build something
that looks like cursors on top of the complete set of tuples.

>
> Another suggestion related to parameters:
>
> > <name> ALIAS FOR $n;
> >
> > For better readability of the code it's possible to
> > define an alias for a positional parameter to the
> > function.
> >
>
> What is the defined behavior if the user leaves out this parameter?
> Do we generate a runtime error? If I might suggest the following:
>
> <name> ALIAS FOR $n;
> sets up name as an alias for $n, name is null if that parameter was
> not given.

The backends main parser chooses functions not only by name.
The number and datatypes of the given parameters must also
match (function overloading - possible with our PL
implementation). If a query execution reaches the function
call, be sure that all parameters are given.

I thought about it just as a way to make the code more
readable. The parameters might also be accessed by the usual
$n notation. So if you have

empname ALIAS FOR $n;

in the declarations, empname and $n are identical. Thats how
I understand the word ALIAS.

>
> <name> REQUIRED ALIAS FOR $n;
> sets up name as an alias for $n, generate a runtime error if that
> parameter was not given.
>
> Actually, an assignment might be a better way to do this. I.E. Define
> foo as int not null, assign $2 to foo and if there is an error, the user is notified.

Does make sense. But for sake a function cannot identify a
null value in one of the parameters. The passed in isNull
flag only says that one of all parameters is null. Not which
one. We have to change this someday, and I have already some
ideas on that. But that's another topic.

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

Browse pgsql-hackers by date

  From Date Subject
Next Message Zeugswetter Andreas 1998-03-13 09:16:25 AW: [HACKERS] PL/pgSQL - for discussion
Previous Message Zeugswetter Andreas 1998-03-13 08:58:17 Re: [HACKERS] PL/pgSQL - for discussion (session global variables)