Mike Rylander wrote:
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?
I think the idea of rewriting PL/PgSQL from scratch has merit (and it's
something that I think would be
On Tue, Nov 23, 2004 at 10:33:50AM -0500, Tom Lane wrote:
We do need to do something about the fact that EXECUTE can't access
plpgsql variables, though I'm afraid that fixing that is going to
require a rather complete overhaul of plpgsql :-(. But it needs one
anyway.
Why do you think that it
I think the idea of rewriting PL/PgSQL from scratch has merit (and it's
something that I think would be well worth doing). IMHO it's not really
worth the trouble to fork the existing code base and add new features to
something that, hopefully, has a limited life span.
I dunno, I kind of
Joachim Wieland [EMAIL PROTECTED] writes:
On Tue, Nov 23, 2004 at 10:33:50AM -0500, Tom Lane wrote:
We do need to do something about the fact that EXECUTE can't access
plpgsql variables, though I'm afraid that fixing that is going to
require a rather complete overhaul of plpgsql :-(. But it
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
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
Matt [EMAIL PROTECTED] writes:
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.
What about
for i in ...
... new.(tg_argv[i]) ...
But
What about
for i in ...
... new.(tg_argv[i]) ...
Ooof! clutches chest, falls to ground groaning Constants or digits or
nothing, then gets up, dusts himself off
MHO: this is a really ugly wart on the language, and it does not solve
the problems people would want to solve.
On Thu, 2004-11-18 at 13:18 +, 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
Hi Neil,
Thanks for the comments. I've actually got (yet) another version ready
to go, which fixes the compile warnings and adds some sanity checks.
I'll post it as soon as I've got beta5 downloaded and tried out :)
FYI, one thing I want to implement is an EVALUATE statement in plpgsql
Hi,
Updated patch (now against beta5) attached. It now pfree's any converted
strings, avoids pointlessly casting an int4oid to int4oid, complies to
CS (uses tabs, not spaces) and works with label.record.(expression) too.
I'm still testing, it now does what I set out to achieve.
I haven't done
Neil Conway [EMAIL PROTECTED] writes:
FYI, one thing I want to implement is an EVALUATE statement in plpgsql
(analogous to eval() in Perl, for example).
I'm confused. How/why is this different from EXECUTE?
regards, tom lane
---(end of
Matt [EMAIL PROTECTED] writes:
Does that make any sense? Is it worth the work? Or should we just tell
anyone who actually needs it (I don't, at present) 'use another PL'?
I don't really see this going anywhere --- it's contorting the semantics
of plpgsql too much for too little gain. The
Hi Tom,
Does that make any sense? Is it worth the work? Or should we just tell
anyone who actually needs it (I don't, at present) 'use another PL'?
I don't really see this going anywhere --- it's contorting the semantics
of plpgsql too much for too little gain.
Yup, the last bit was
On Mon, 2004-11-22 at 10:57 -0500, Tom Lane wrote:
I'm confused. How/why is this different from EXECUTE?
EVALUATE would take a string and evaluate it as a PL/PgSQL statement;
EXECUTE takes a string and executes it as a SQL statement. We've
discussed this before (although I may not have called
On Mon, 2004-11-22 at 10:06 +, Matt wrote:
This would execute a string and pass back the result?
It would evaluate a string as a PL/PgSQL statement (which means you
could construct any PL/PgSQL statement dynamically, including access to
fields of a RECORD determined at runtime).
I don't
Hi all,
I've cleaned this up a bit so that assigning to a dynamic record field
now works - ie NEW.(myvar) := 'someval' - and accessing a field by
number works - ie myvar := OLD.(1)
It still doesn't work in a loop if the type of field referenced by the
expression changes - looking at it more I'm
Hi,
I got extremely frustrated with having to create a temp table every time
I wanted to access an arbitrary column from a record plpgsql. After
seeing a note on the developers TODO about accessing plpgsql records
with a 'dot bracket' notation I started digging into the plpgsql source.
My diff
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?
I lie! pgpgsql_read_expression() is smarter than that!
However, I
19 matches
Mail list logo
