Re: [rfc,patch] PL/Proxy in core - Mailing list pgsql-hackers

From Marko Kreen
Subject Re: [rfc,patch] PL/Proxy in core
Date
Msg-id e51f66da0805150118t6f0b30fdud73927d6d4395c06@mail.gmail.com
Whole thread Raw
In response to Re: [rfc,patch] PL/Proxy in core  ("Marko Kreen" <markokr@gmail.com>)
List pgsql-hackers
On 5/15/08, Marko Kreen <markokr@gmail.com> wrote:
> On 5/15/08, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>  > "Marko Kreen" <markokr@gmail.com> writes:
>  >  > Hmm.. Now that I think about it, in my effort to remove malloc() calls
>  >  > in both scanner and parser I told bison to use alloca().  Is it portability
>  >  > concern?
>  >
>  > Yes.
>
>
> How about following patch?  I have bison 2.3 and it seems not to do
>  global allocation, so it should be fine.  There may be early exit
>  with elog(ERRROR) inside so I'd like to avoid malloc() itself.
>
>  Is there some older bison that keeps allocations around?
>  They would need bit more work...
>
>  --- src/parser.y        14 May 2008 12:25:00 -0000      1.7
>  +++ src/parser.y        15 May 2008 07:34:53 -0000
>  @@ -24,7 +24,9 @@
>   void plproxy_yy_scan_bytes(const char *bytes, int len);
>
>   /* avoid permanent allocations */
>  -#define YYSTACK_USE_ALLOCA 1
>  +#define YYMALLOC palloc
>  +#define YYFREE pfree
>  +
>   /* remove unused code */
>   #define YY_LOCATION_PRINT(File, Loc) (0)
>   #define YY_(x) (x)
>
>  I will roll new full patch when more comments have appeared.

Checked bison 1.875, and it does not use YYMALLOC/YYFREE.
But luckily its allocation pattern seems sane, so following should work:

--- src/parser.y    14 May 2008 12:25:00 -0000    1.7
+++ src/parser.y    15 May 2008 08:18:14 -0000
@@ -24,7 +24,9 @@void plproxy_yy_scan_bytes(const char *bytes, int len);
/* avoid permanent allocations */
-#define YYSTACK_USE_ALLOCA 1
+#define malloc palloc
+#define free pfree
+/* remove unused code */#define YY_LOCATION_PRINT(File, Loc) (0)#define YY_(x) (x)

-- 
marko


pgsql-hackers by date:

Previous
From: "Marko Kreen"
Date:
Subject: Re: [rfc,patch] PL/Proxy in core
Next
From: Nikhils
Date:
Subject: Re: Can't t compile current HEAD