The portability of C-with-embedded-SQL ecpg-style.

I have a system that I am trying to put together: eventually, the
target will be WIN32 and the Borland InterBase V4.x product (which is,
BTW, not my choice), but for now I am developing on NetBSD and I am
hoping to be able to roll PostgreSQL into the development process.

The database side of this system comprises ~30 or 40 tables which
might get to be rather sizey; the system code is written in C, but it
is riddled with embedded SQL---a job for ecpg, no doubt.

Firstly, I am in the process of pulling all of the embedded SQL out of
my system modules and into a separate library, and I am hoping that
one of the consequences of this action will be to greatly ease porting
to other database platforms should the need arise---particularly the
InterBase thing because that need has /already/ arisen :) On the face
of this, is this a stupid idea? I recognise that a better alternative
might be to write so as to use one or other of libpg or libpg++, but I
figure that such an approach might present obstacles to portability
(what does Borland's library look like? MS SQL Server's? etc.?).

Secondly, I am interested in any known issues of portability between
C-with-embedded-SQL preprocessors: can I reasonably expect EXEC SQLs
for static SELECTs and DECLAREs to be reasonably portable between
different engines? I am not planning on any fancy dynamic SQL, nor
even PREPARE---there are one or two cursors that have SELECTs in a
WHERE clause, but that's about it.

FWIW, I have skimmed the relevant pieces of the PostgreSQL
Programmer's Guide---the specifics on portability and ecpg are marked
as "under construction", which is fair enough. Still, is there any
experience on this list from which I can draw?

--Kevin.
kevinc(at)premium(dot)com(dot)au