Subject: Re: ?

From: [email-masked] (Niranjan Perera)
Date: Sat, 12 Mar 94 08:05:40 EST

Hi:

I am trying to interface a program to the postgres backend. I am using
flex, bison, libpq, and gcc 2.5.8.

PROBLEM:
I get a core dump :( when I try to yyparse(). The problem reported by
gdb is that it occurs in malloc() ( inside the lex generated code ).

I can get the program to run using lex, yacc, and cc ( K&R C ), but would
prefer to use ANSI C.

QUESTION:
Has anybody been able to use flex, bison, and gcc 2.5.8 to compile against
the backend ? If so, How does one get around the malloc() problem ? I even
tried using palloc().

Any suggestions or hints ?

-- Niranjan

p.s The version of postgres is 4.1, and it is a precompiled sparc binary.

---

From: [email-masked] (Paul M. Aoki)
Date: Wed, 23 Mar 94 17:42:16 -0800

> flex, bison, libpq, and gcc 2.5.8.

1. postgres already has its own yyparse, etc. for its own grammar.
defining your own parser with default symbol names causes symbol 
conflicts.  find out how your lexer/yaccer let you avoid defining 
symbols starting in "yy".

2. libpq isn't supposed to be used in backend functions.  the current
release of postgres gives you something like the PQexec/portal 
interface but (1) you don't link in libpq, stubs are provided in the
backend, and (2) its use is somewhat problematic inasmuch as all
PQexecs are executed as subcommands in the same transaction.  this
has memory management (exhaustion) implications as well as the
obvious transaction-related implications.

3. don't use gcc for user-defined functions on sparcs.  postgres
makes some assumptions about alignment of doubles that the sun 
compiler lets slide but gcc does not.  (if you don't use doubles,
it's not a problem, but if you do, you may end up with bus errors.)
--
  Paul M. Aoki  |  CS Div., Dept. of EECS, UCB  |  [email-masked]
                |  Berkeley, CA 94720           |  ...!uunet!ucbvax!aoki