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 [EMAIL PROTECTED] GPLS -- PINES Development Database Developer On 23 Nov 2004 09:03:10 +0000, Matt <[EMAIL PROTECTED]> 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 > ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
