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

Just to put in my .02$, I would absolutely love to see this
functionality included in plpgsql. With some extra error checking for
the know changing datatype failure, and docs that mention that
limitation, I'd say this is a great extension to the language.
plpgsql feels quicker than the interpreted PLs and it's far easier
than C to work with for writing triggers, so this patch makes plpgsql
a much more attractive target for general purpose stored procs. And
my gut feeling is that an EVALUATE statement would be significantly
slower than this.

In any case, thanks for the great work, Matt. Please, CORE, include this one!

As an alternative, what would be the possibility of creating a new PL
as a contrib module, say PLPGSQL_NG, to move forward with extensions
like this and perhaps EVALUATE?

--
Mike Rylander
mrylander(at)gmail(dot)com
GPLS -- PINES Development
Database Developer

On 23 Nov 2004 09:03:10 +0000, Matt <matt(at)kynx(dot)org> wrote:
> > > See your point. But what about NEW.($1)?
> >
> > I don't follow -- what do you mean?
>
> I want to be able to be able to write a trigger function that accesses a
> column passed as an argument to the function in the row that caused the
> trigger. This is my use case.
>
> I guess that would actually written NEW.(TG_ARGV[1]).
>
> > (BTW, I think my comment also applies to variables of type "text" and
> > similar -- I think the patch would be a lot simpler if you just
> > implement access to record fields by ordinal position, and don't
> > implement access by field name.)
>
> Yes, it would be marginally simpler: I'd still have to call
> exec_eval_datum() on the variable and check whether it could be
> evaluated to an integer (trigger args are all text AFAIK). The only
> difference would be throwing an error if it wasn't, instead of making
> use of the value... and a slightly less readable 'create trigger'
> statement.
>
> It would be a good idea to check that the variable was either a constant
> or a trigger arg. This would stop the looping problem, since the type of
> the underlying field couldn't change.
>
> But I've somehow got the feeling that this sort of thing isn't the
> issue. The issue is whether we want to allow dynamic access to columns
> in any syntax at all. A simple yes or no would do :)
>
> Matt
>
> BTW: here's the original post adding the rec.(3) syntax to the TODO:
> http://archives.postgresql.org/pgsql-hackers/2003-07/msg00425.php
> here's someone else who tried something very similar:
> http://archives.postgresql.org/pgsql-hackers/2003-09/msg00533.php
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>