Thread: BUG #1962: ECPG and VARCHAR
The following bug has been logged online: Bug reference: 1962 Logged by: Charles Wegrzyn Email address: lists@garbagedump.com PostgreSQL version: 8.0.4 Operating system: Linux : 2.6.13-r4 Description: ECPG and VARCHAR Details: I have code that under 8.0.3 works: VARCHAR t[MAX_TENANT_SIZE+1]; VARCHAR o[MAX_OID_SIZE+1]; In 8.0.4 I found this throws an error during the ecpg step: tenant.ec:375: ERROR: pointer to varchar are not implemented tenant.ec:376: ERROR: pointer to varchar are not implemented
On Thu, Oct 13, 2005 at 02:24:27PM +0100, Charles Wegrzyn wrote:
> I have code that under 8.0.3 works:
>
> VARCHAR t[MAX_TENANT_SIZE+1];
> VARCHAR o[MAX_OID_SIZE+1];
>
> In 8.0.4 I found this throws an error during the ecpg step:
>
> tenant.ec:375: ERROR: pointer to varchar are not implemented
> tenant.ec:376: ERROR: pointer to varchar are not implemented
ecpg in 8.0.4 seems not to like the macros. I get the same error,
but not if I do this:
VARCHAR t[256];
VARCHAR o[256];
ecpg in 8.1beta3 works either way.
--
Michael Fuhr
On Thu, Oct 13, 2005 at 09:49:20AM -0600, Michael Fuhr wrote: > ecpg in 8.0.4 seems not to like the macros. I get the same error, > but not if I do this: > > VARCHAR t[256]; > VARCHAR o[256]; > > ecpg in 8.1beta3 works either way. This appears to be the guilty commit, which was made to 7.4, 8.0, and HEAD (8.1): http://archives.postgresql.org/pgsql-committers/2005-08/msg00266.php It was recently fixed in HEAD only: http://archives.postgresql.org/pgsql-committers/2005-10/msg00043.php -- Michael Fuhr
Michael Fuhr wrote: > On Thu, Oct 13, 2005 at 09:49:20AM -0600, Michael Fuhr wrote: > > ecpg in 8.0.4 seems not to like the macros. I get the same error, > > but not if I do this: > > > > VARCHAR t[256]; > > VARCHAR o[256]; > > > > ecpg in 8.1beta3 works either way. > > This appears to be the guilty commit, which was made to 7.4, 8.0, > and HEAD (8.1): > > http://archives.postgresql.org/pgsql-committers/2005-08/msg00266.php > > It was recently fixed in HEAD only: > > http://archives.postgresql.org/pgsql-committers/2005-10/msg00043.php Good catch! I have backpatched these fixes to the 8.0 and 7.4 branches as you suggested, (identical) patches attached. The big problem is that we might not make releases on these branches for months, so anyone needing the fix should download CVS for those branches. -- 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 Index: src/interfaces/ecpg/preproc/preproc.y =================================================================== RCS file: /cvsroot/pgsql/src/interfaces/ecpg/preproc/preproc.y,v retrieving revision 1.303.4.4 diff -c -c -r1.303.4.4 preproc.y *** src/interfaces/ecpg/preproc/preproc.y 24 Aug 2005 10:35:12 -0000 1.303.4.4 --- src/interfaces/ecpg/preproc/preproc.y 14 Oct 2005 01:47:05 -0000 *************** *** 5142,5149 **** *dim = '\0'; else sprintf(dim, "[%s]", dimension); ! /* if (strcmp(length, "0") == 0)*/ ! if (atoi(length) <= 0) mmerror(PARSE_ERROR, ET_ERROR, "pointer to varchar are not implemented"); if (strcmp(dimension, "0") == 0) --- 5142,5149 ---- *dim = '\0'; else sprintf(dim, "[%s]", dimension); ! /* cannot check for atoi <= 0 because a defined constant will yield 0 here as well */ ! if (atoi(length) < 0 || strcmp(length, "0") == 0) mmerror(PARSE_ERROR, ET_ERROR, "pointer to varchar are not implemented"); if (strcmp(dimension, "0") == 0) Index: src/interfaces/ecpg/preproc/preproc.y =================================================================== RCS file: /cvsroot/pgsql/src/interfaces/ecpg/preproc/preproc.y,v retrieving revision 1.263.2.20 diff -c -c -r1.263.2.20 preproc.y *** src/interfaces/ecpg/preproc/preproc.y 24 Aug 2005 10:35:54 -0000 1.263.2.20 --- src/interfaces/ecpg/preproc/preproc.y 14 Oct 2005 01:47:43 -0000 *************** *** 5121,5128 **** *dim = '\0'; else sprintf(dim, "[%s]", dimension); ! /* if (strcmp(length, "0") == 0)*/ ! if (atoi(length) <= 0) mmerror(PARSE_ERROR, ET_ERROR, "pointer to varchar are not implemented"); if (strcmp(dimension, "0") == 0) --- 5121,5128 ---- *dim = '\0'; else sprintf(dim, "[%s]", dimension); ! /* cannot check for atoi <= 0 because a defined constant will yield 0 here as well */ ! if (atoi(length) < 0 || strcmp(length, "0") == 0) mmerror(PARSE_ERROR, ET_ERROR, "pointer to varchar are not implemented"); if (strcmp(dimension, "0") == 0)
Michael Fuhr wrote: >On Thu, Oct 13, 2005 at 02:24:27PM +0100, Charles Wegrzyn wrote: > > >>I have code that under 8.0.3 works: >> >> VARCHAR t[MAX_TENANT_SIZE+1]; >> VARCHAR o[MAX_OID_SIZE+1]; >> >>In 8.0.4 I found this throws an error during the ecpg step: >> >>tenant.ec:375: ERROR: pointer to varchar are not implemented >>tenant.ec:376: ERROR: pointer to varchar are not implemented >> >> > >ecpg in 8.0.4 seems not to like the macros. I get the same error, >but not if I do this: > > VARCHAR t[256]; > VARCHAR o[256]; > >ecpg in 8.1beta3 works either way. > > > Michael, Yes I found out the same thing. Unfortunately it isn't quite that simple for me. It isn't a very good idea to hard-code fixed sizes in executables. I have a file with all sorts of #defines in it. If the bug doesn't get fixed it means that I will need to run CPP over the code before I run ecpg, which is just ugly. Chuck Wegrzyn
On Thu, Oct 13, 2005 at 09:53:14PM -0400, Bruce Momjian wrote: > Good catch! I have backpatched these fixes to the 8.0 and 7.4 branches > as you suggested, (identical) patches attached. Thanks Bruce. This was an oversight on my part. I should have committed to 8.0 branch too. I'm sorry about that. On the other hand I agree with Tom. Fortunately it's not a data corruption problem. :-) Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
On Thu, Oct 13, 2005 at 11:18:13AM -0500, C Wegrzyn wrote: > Yes I found out the same thing. Unfortunately it isn't quite that > simple for me. It isn't a very good idea to hard-code fixed sizes in > executables. I have a file with all sorts of #defines in it. If the bug > doesn't get fixed it means that I will need to run CPP over the code > before I run ecpg, which is just ugly. Can't you just compile a new version of ecpg with the patch Bruce committed? Depending on the system you're using I could even send you a binary. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
The customer I am writing this for will only accept it based on released code. That means I run either 8.0.3 or 8.0.4. Chuck Michael Meskes wrote: >On Thu, Oct 13, 2005 at 11:18:13AM -0500, C Wegrzyn wrote: > > >> Yes I found out the same thing. Unfortunately it isn't quite that >>simple for me. It isn't a very good idea to hard-code fixed sizes in >>executables. I have a file with all sorts of #defines in it. If the bug >>doesn't get fixed it means that I will need to run CPP over the code >>before I run ecpg, which is just ugly. >> >> > >Can't you just compile a new version of ecpg with the patch Bruce >committed? Depending on the system you're using I could even send you a >binary. > >Michael > >
Am Freitag, 14. Oktober 2005 21:15 schrieb C Wegrzyn: > The customer I am writing this for will only accept it based on released > code. That means I run either 8.0.3 or 8.0.4. Would it help you if I do a special ecpg release just for you? Or does it have to be part of the postgres release? Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!