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 wou
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
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
On Thu, 2005-01-20 at 07:57 -0500, Tom Lane wrote:
> Not sure, but it seems like at least as straightforward a translation
> as the other way. More to the point, it makes clear the difference
> between what is meant to be a long-lived data structure and what isn't.
The latter point is sound, I th
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 pf
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 parsi
On Mon, 2005-02-07 at 19:22 -0500, Tom Lane wrote:
> What might work is to run in the function context as the basic state,
> but switch to a short-term context when calling any main-backend code
> from pl_comp.c. I'm not sure how many such calls there are, but if it's
> not more than a dozen or tw
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 call
On Mon, 2005-02-07 at 21:25 -0500, Tom Lane wrote:
> I haven't looked lately, but my recollection is that there are just a
> few calls into the main backend from pl_comp.c. I'm not sure they are
> all to backend/parser though; check /catalog, etc as well.
Attached is a patch that implements this.
When you apply this, please put the remaining array-overflow checks
before the overflow occurs, not after. See patches I just applied
in the back branches.
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9' th
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 in
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
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 most
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 funct
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 'plpgsql
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.
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
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 FOR-o
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 anyt
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 in
On Thu, 2005-02-10 at 23:32 -0500, Tom Lane wrote:
> Congratulations, you just reinvented the scheme we used before 8.0.
> It's *not* an improvement. The dot-dot business is better.
Right -- but it's not very good either, and I was trying to find a
proper solution. For now I've given up and rever
Neil Conway <[EMAIL PROTECTED]> writes:
> Attached is a revised patch that incorporates your suggestions. Sorry
> for the delay in posting this.
Still a few bricks shy of a load I fear:
regression=# create or replace function foo() returns int language plpgsql as $$
regression$# begin
regression$
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 c
Neil Conway wrote:
Attached is a revised patch.
Applied to HEAD.
-Neil
---(end of broadcast)---
TIP 8: explain analyze is your friend
25 matches
Mail list logo
