Skip site navigation (1) Skip section navigation (2)

Re: ECGP - varchar in struct?

From: Michael Meskes <meskes(at)postgresql(dot)org>
To: William West <wwest(at)csc(dot)com>
Cc: pgsql-interfaces(at)postgresql(dot)org
Subject: Re: ECGP - varchar in struct?
Date: 2002-08-11 13:58:51
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-interfaces
On Fri, Jul 26, 2002 at 09:38:25PM -0400, William West wrote:
> It would appear that ecpg will only re-write a
> varchar if it is found in a DECLARE statement,
> because the varchar gets past the ecpg preprocessor's
> INCLUDE as-is ... and, of course, the real C compiler
> does not know what a 'varchar' is, so it complains.

Yes, ecpg only parses stuff inside the declare section. A full syntax
checking mode would be a nice add-on (and is listed as todo) but IMO it
is not really needed urgently.

> As a PostgreSQL 'newbie', I am not sure if it is more
> work to fix ecpg or to re-write how the application
> does things. I see it is a 'yacc' unit that handles the
> re-writing that ecpg now does, but I do not know
> 'yacc-ese' and do not know what else would be involved
> to fix ecpg to work like PRO-C?

Yes, it's quite some work. :-) But if you volunteer I gladly accept
patches. :-)

> - Did I miss something here?

Yes, at first you can list you struct definition inside the declare
section and it will work nicely.

And second you can use a typedef command that AFAIK Pro*C does not have.

This should help you without much work.

>   varchar re-writes during INCLUDE and not
>   just during DECLARE?

Actually it does not have anything to do with INCLUDE or I misunderstood
your problem comletely.

Hope this helps.

Michael Meskes
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!

In response to

pgsql-interfaces by date

Next:From: William WestDate: 2002-08-11 21:14:07
Subject: Re: ECGP - varchar in struct?
Previous:From: g.hintermayerDate: 2002-08-08 08:52:13
Subject: libpgtcl modifications

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group