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 :-(.
> 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
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
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 we
> What about
> for i in ...
> ... new.(tg_argv[i]) ...
Ooof! Constants or digits or
nothing, then
> MHO: this is a really ugly wart on the language, and it does not solve
> the problems people would want to solve. It might solve *your* problem
> but that's not enough to jus
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]) ...
>
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 interprete
> > 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
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
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 i
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
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 ty
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 broad
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 any
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
> (analo
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 example
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 r
> 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
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 (a
19 matches
Mail list logo
