Thread: ecpg problem in 7.4 beta
I tried running ecpg in 7.4 beta and got:$ ecpg x.pgc$ gcc -I/usr/local/pgsql/include -L/usr/local/pgsql/lib -lpgtypes -lecpgx.cIn file included from x.c:4:/usr/local/pgsql/include/ecpglib.h:9: postgres_fe.h: No such file ordirectory Why is ecpglib.h referencing postgres_fe.h? I only see postgres_fe.h in the install directory under pgsql/include/internal. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
I now remember Michael is away for a week or two. We will have to wait for his return. --------------------------------------------------------------------------- Bruce Momjian wrote: > I tried running ecpg in 7.4 beta and got: > > $ ecpg x.pgc > $ gcc -I/usr/local/pgsql/include -L/usr/local/pgsql/lib -lpgtypes -lecpg x.c > In file included from x.c:4: > /usr/local/pgsql/include/ecpglib.h:9: postgres_fe.h: No such file or > directory > > Why is ecpglib.h referencing postgres_fe.h? I only see postgres_fe.h in > the install directory under pgsql/include/internal. > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup. | Newtown Square, Pennsylvania 19073 > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
OK, I think I can fix this. The include of postgres_fe.h was done recently:revision 1.54date: 2003/08/01 13:53:36; author: petere; state: Exp; lines: +4 -2Make ecpg SQLSTATE-aware. Mapexisting SQLCODE assignments to SQLSTATEs,rather than parsing the message. Add some documentation about embeddedSQL. It seems like doing postgres_fe.h rather than postgres_ext.h was just an oversight, so I will make the change in CVS. --------------------------------------------------------------------------- Bruce Momjian wrote: > I tried running ecpg in 7.4 beta and got: > > $ ecpg x.pgc > $ gcc -I/usr/local/pgsql/include -L/usr/local/pgsql/lib -lpgtypes -lecpg x.c > In file included from x.c:4: > /usr/local/pgsql/include/ecpglib.h:9: postgres_fe.h: No such file or > directory > > Why is ecpglib.h referencing postgres_fe.h? I only see postgres_fe.h in > the install directory under pgsql/include/internal. > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup. | Newtown Square, Pennsylvania 19073 > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> OK, I think I can fix this. The include of postgres_fe.h was done
> recently:
> revision 1.54
> date: 2003/08/01 13:53:36; author: petere; state: Exp; lines: +4 -2
> Make ecpg SQLSTATE-aware. Map existing SQLCODE assignments to SQLSTATEs,
> rather than parsing the message. Add some documentation about embedded
> SQL.
> It seems like doing postgres_fe.h rather than postgres_ext.h was just an
> oversight, so I will make the change in CVS.
I think you will break things if you do. It's unlikely Peter changed
that on a whim --- ecpg probably now requires more than it did before.
I am not sure that we want to start treating postgres_fe.h as a public
header though --- if we do, that means also c.h and perhaps other stuff.
This needs some thought.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > OK, I think I can fix this. The include of postgres_fe.h was done > > recently: > > > revision 1.54 > > date: 2003/08/01 13:53:36; author: petere; state: Exp; lines: +4 -2 > > Make ecpg SQLSTATE-aware. Map existing SQLCODE assignments to SQLSTATEs, > > rather than parsing the message. Add some documentation about embedded > > SQL. > > > It seems like doing postgres_fe.h rather than postgres_ext.h was just an > > oversight, so I will make the change in CVS. > > I think you will break things if you do. It's unlikely Peter changed > that on a whim --- ecpg probably now requires more than it did before. Peter added libpq_fe.h at the same time, and there is no mention in the commit logs, so I think it was a general cleanup of which things are included. > I am not sure that we want to start treating postgres_fe.h as a public > header though --- if we do, that means also c.h and perhaps other stuff. > This needs some thought. Right. postgres_ext.h works fine in my testing and is the more natural interface. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian writes: > It seems like doing postgres_fe.h rather than postgres_ext.h was just an > oversight, so I will make the change in CVS. No, postgres_fe.h shouldn't have been used there at all, that was just a mistake. I will remove postgres_ext.h as well. -- Peter Eisentraut peter_e@gmx.net