Neil Conway wrote:
Attached is a revised patch.
Applied to HEAD.
-Neil
---(end of broadcast)---
TIP 8: explain analyze is your friend
Tom Lane wrote:
Still a few bricks shy of a load I fear [...]
My apologies; thanks for the code review.
regression=# create or replace function foo() returns int language plpgsql as $$
regression$# begin
regression$# return ;
regression$# end$$;
CREATE FUNCTION
regression=# select foo();
server
Neil Conway [EMAIL PROTECTED] writes:
On Wed, 2005-02-09 at 23:57 -0500, Tom Lane wrote:
That seems like a step backwards from the current behavior [...]
Hmm, fair enough. Is this better?
Yeah, looks better, though I question the use of embedded in the
message --- seems a bit jargony. Are
On Thu, 2005-02-10 at 10:15 -0500, Tom Lane wrote:
Yeah, looks better, though I question the use of embedded in the
message --- seems a bit jargony. Are you going to post a revised patch?
Actually the code to present error messages as in the previous message
was in the previous patch, just #if
Neil Conway [EMAIL PROTECTED] writes:
Attached is a revised patch that removes embedded and updates the
regression tests. I'll apply this to HEAD later today barring any
further suggestions for improvement.
You've broken the FOR syntax. You may not assume that the first token
of a
On Thu, 2005-02-10 at 20:48 -0500, Tom Lane wrote:
You've broken the FOR syntax. You may not assume that the first token
of a FOR-over-SELECT is literally SELECT; it could for example be a left
parenthesis starting some kind of UNION construct.
Yeah, I was wondering if this would break
Neil Conway [EMAIL PROTECTED] writes:
... Looking for two periods is pretty ugly. I was thinking we
might be able to look at the for loop variable: if it was previously
undeclared, it must be an integer for loop. If it was declared but is
not of a row or record type, it must also be an integer
Another version of the patch is attached. Changes:
- clean up grammar so that read_sql_construct() is always called to read
a well-formed SQL expression. That way we can check for errors in
embedded SQL by just adding a single function call to
read_sql_construct(), rather than adding calls at
Neil Conway [EMAIL PROTECTED] writes:
create function bad_sql1() returns int as $$
declare a int;
begin
a := 5;
Johnny Yuma;
a := 10;
return a;
end$$ language 'plpgsql';
ERROR: syntax error at or near Johnny
CONTEXT: SQL statement embedded in PL/PgSQL function bad_sql1
On Wed, 2005-02-09 at 23:57 -0500, Tom Lane wrote:
That seems like a step backwards from the current behavior [...]
Hmm, fair enough. Is this better?
create function bad_sql1() returns int as $$
declare a int;
begin
a := 5;
Johnny Yuma;
a := 10;
return a;
end$$ language
Neil Conway [EMAIL PROTECTED] writes:
BTW, both of our fixes suffer from the deficiency that they will
actually reject input one variable too early: we disallow a SQL
statement with 1023 variables that we strictly speaking could store.
Right. I thought about putting the overflow checks inside
On Tue, 2005-02-08 at 13:25 -0500, Tom Lane wrote:
When you apply this, please put the remaining array-overflow checks
before the overflow occurs, not after.
Actually, my original fix _does_ check for the overflow before it
occurs. ISTM both fixes are essentially identical, although yours may
Neil Conway [EMAIL PROTECTED] writes:
- abandonded the falloc() idea. There really aren't that many
short-lived allocations in the PL/PgSQL compiler, and using falloc()
made it difficult to use List. Instead, make the CurrentMemoryContext
the long-lived function context, and explicitly pfree
On Mon, 2005-02-07 at 10:41 -0500, Tom Lane wrote:
My recollection is that I was not nearly as worried about short-term
pallocs in the plpgsql code itself, as about leakage in various main-
backend routines that get called incidentally during parsing.
backend/parser/ is quite cavalier about
Neil Conway [EMAIL PROTECTED] writes:
On Mon, 2005-02-07 at 10:41 -0500, Tom Lane wrote:
My recollection is that I was not nearly as worried about short-term
pallocs in the plpgsql code itself, as about leakage in various main-
backend routines that get called incidentally during parsing.
Neil Conway [EMAIL PROTECTED] writes:
WRT calls to backend/parser, I can see LookupTypeName (pl_comp.c:1060),
and parseTypeString (pl_comp.c:1627). Are these the only calls you had
in mind, or am I missing some?
I haven't looked lately, but my recollection is that there are just a
few calls
Neil Conway [EMAIL PROTECTED] writes:
On Tue, 2005-01-18 at 01:02 -0500, Tom Lane wrote:
It might be better to keep CurrentMemoryContext pointing at a temp
context, and translate malloc() to MemoryContextAlloc(function_context)
rather than just palloc(). (Of course you could hide this in a
On Thu, 2005-01-20 at 15:48 +1100, Neil Conway wrote:
Attached is a revised patch (no major changes, just grammar cleanup).
While rewriting some cruft in PL/PgSQL's gram.y, I noticed that we will
overflow a heap-allocated array if the user specifies more than 1024
parameters to a refcursor (a
Neil Conway [EMAIL PROTECTED] writes:
This patch makes a number of cleanups to PL/PgSQL:
- replaced all uses of malloc/strdup with palloc/pstrdup.
...
(This was surprisingly easy, btw, so I am suspect that I've missed
something fundamental -- hence the patch is marked WIP. Guidance would
be
19 matches
Mail list logo
