Re: patch: plpgsql - access records with rec.(expr)

On Thu, 2004-11-18 at 13:18 +0000, Matt wrote:
> I got extremely frustrated with having to create a temp table every time
> I wanted to access an arbitrary column from a record plpgsql.

FYI, one thing I want to implement is an EVALUATE statement in plpgsql
(analogous to eval() in Perl, for example). If I understand your use
case, I think this will help somewhat, although of course it is still
clumsier than direct syntactic support.

> Warning: I Am Not a C Programmer! I haven't even written a hello world
> in C before, and I knew nothing about Flex before yesterday. It was fun
> figuring stuff out, I'm amazed it mostly works, but I'm really hoping
> someone can point out my mistakes.

An impressive first hack! :)

> Enable users to access fields in record variables using the following
> syntax like the following [...]

>   rec.(1)

Looks good.

>   rec.('foo')

I don't like this: it implicitly coerces a string literal into an
identifier (i.e. a column name). Treating data as code can be useful,
but I think we need to make it more obvious to the user. I think a
proper EVALUATE statement might be a better solution.

> 5. Because of the way the expression is parsed (looking for closing
> parenth), this will choke if you try and put a function in there. Would
> it be better to use curly braces '{expr}' or another character to mark
> the expression?

How much thought went into choosing parentheses? (i.e. is a similar
syntax used in the procedural languages in other DBs?)

In any case, I don't think switching switching to braces is the right
solution to the lexing problem. I _believe_ the patch is OK as is --
plpgsql_read_expression() keeps track of parenthesis nesting so it
should be able to figure out when it sees an "unmatched" parenthesis
(indicating the end of the expression).

BTW, attached is a trivial incremental patch that fixes a few compile
warnings (which are indicative of actual problems) in your patch.

-Neil