From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200308071415.h77EFMW25868@candle.pha.pa.us>
Subject: Re: ecpg problem in 7.4 beta
In-Reply-To: <14915.1060264281@sss.pgh.pa.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Thu, 7 Aug 2003 10:15:22 -0400 (EDT)
Cc: PostgreSQL-interfaces <pgsql-interfaces@postgresql.org>,
	Peter Eisentraut <peter_e@gmx.net>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII

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, Pennsylvania 19073