BUG #1962: ECPG and VARCHAR

Started by Charles Wegrzynabout 20 years ago15 messages

lists@garbagedump.com

about 20 years ago

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

Michael Fuhr

mike@fuhr.org

about 20 years ago

In reply to: Charles Wegrzyn (#1)

Re: BUG #1962: ECPG and VARCHAR

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

C Wegrzyn

lists@garbagedump.com

about 20 years ago

In reply to: Michael Fuhr (#2)

Re: BUG #1962: ECPG and VARCHAR

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

Michael Fuhr

mike@fuhr.org

about 20 years ago

In reply to: Michael Fuhr (#2)

Re: BUG #1962: ECPG and VARCHAR

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

Bruce Momjian

pgman@candle.pha.pa.us

about 20 years ago

In reply to: Michael Fuhr (#4)

2 attachment(s)

Re: BUG #1962: ECPG and VARCHAR

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

Attachments:

/rtmp/difftext/plainDownload

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)

/rtmp/diff2text/plainDownload

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 Paesold

mpaesold@gmx.at

about 20 years ago

In reply to: Bruce Momjian (#5)

Re: [PATCHES] [BUGS] BUG #1962: ECPG and VARCHAR

[moved to hackers]

Is this a regression in the stable branches? If so, shouldn't we do a new
release rather immediately? What do others think about this situation?

Can you remember regressions in stable branches in the past? How were those
it handled? I think "waiting for months" (i.e. for the next major bug fixes)
is not the correct answer here. IMHO, the latest released version should be
known best in all components.

Best Regards,
Michael Paesold

Bruce Momjian wrote:

Show quoted text

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.

Tom Lane

tgl@sss.pgh.pa.us

about 20 years ago

In reply to: Michael Paesold (#6)

Re: [PATCHES] [BUGS] BUG #1962: ECPG and VARCHAR

"Michael Paesold" <mpaesold@gmx.at> writes:

Can you remember regressions in stable branches in the past?

Yes. Relax. If this were a data-corruption-in-the-backend issue,
I might feel that it mandates an immediate re-release. But it isn't
and it doesn't. You'll note that Michael M. himself didn't bother to
backpatch the fix on first discovery ... so why should anyone else
take it more seriously?

regards, tom lane

Michael Paesold

mpaesold@gmx.at

about 20 years ago

In reply to: Bruce Momjian (#5)

Re: [PATCHES] [BUGS] BUG #1962: ECPG and VARCHAR

Tom Lane wrote:

"Michael Paesold" <mpaesold@gmx.at> writes:

Can you remember regressions in stable branches in the past?

Yes. Relax. If this were a data-corruption-in-the-backend issue,
I might feel that it mandates an immediate re-release. But it isn't
and it doesn't. You'll note that Michael M. himself didn't bother to
backpatch the fix on first discovery ... so why should anyone else
take it more seriously?

OK. :-)

Michael Paesold

Bruce Momjian

pgman@candle.pha.pa.us

about 20 years ago

In reply to: Michael Paesold (#6)

Re: [PATCHES] [BUGS] BUG #1962: ECPG and VARCHAR

Michael Paesold wrote:

[moved to hackers]

Is this a regression in the stable branches? If so, shouldn't we do a new
release rather immediately? What do others think about this situation?

Can you remember regressions in stable branches in the past? How were those
it handled? I think "waiting for months" (i.e. for the next major bug fixes)
is not the correct answer here. IMHO, the latest released version should be
known best in all components.

Yea, it is a regression, and yea, we hate when that happens. Let's see
how many people have a problem with it and we can review if we need a
minor release to fix it.

---------------------------------------------------------------------------

Best Regards,
Michael Paesold

Bruce Momjian wrote:

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.

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

-- 
  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

#10

C Wegrzyn

lists@garbagedump.com

about 20 years ago

In reply to: Bruce Momjian (#9)

Re: [PATCHES] [BUGS] BUG #1962: ECPG and VARCHAR

First, let me thank you for the effort you have been putting into the
Postgresql development. It is a great system. It performs well and with
the exception of a few little annoyances is a great competitor to Mysql
or Oracle!

This particular bug isn't a show stopper; I could have easily found a
way around it if I wanted to. Instead I decided to fall back to 8.0.3
since this will be fixed hopefully in 8.0.5. But it did make me think
of something else.

I would like to make a suggestion, if you don't mind. I don't mind
running the bleeding edge of things, and if you go to the gentoo bugs
you will see quite a few posted by me. My suggestion - and it might be
simply due to my not knowing where to look - is perhaps there should be
a simple way to find the bugs that are still outstanding or when they
resolved or how. On bugs.gentoo.org I can type in CUPS for example and
find out everything - resolved, past and present and outstanding, bugs
related to cups. I can find nothing on the postgresql site.

FWIW,
Chuck Wegrzyn

Bruce Momjian wrote:

Show quoted text

Michael Paesold wrote:

[moved to hackers]

Is this a regression in the stable branches? If so, shouldn't we do a new
release rather immediately? What do others think about this situation?

Can you remember regressions in stable branches in the past? How were those
it handled? I think "waiting for months" (i.e. for the next major bug fixes)
is not the correct answer here. IMHO, the latest released version should be
known best in all components.

Yea, it is a regression, and yea, we hate when that happens. Let's see
how many people have a problem with it and we can review if we need a
minor release to fix it.

---------------------------------------------------------------------------

Best Regards,
Michael Paesold

Bruce Momjian wrote:

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.

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

#11

Bruce Momjian

pgman@candle.pha.pa.us

about 20 years ago

In reply to: C Wegrzyn (#10)

Re: [PATCHES] [BUGS] BUG #1962: ECPG and VARCHAR

C Wegrzyn wrote:

First, let me thank you for the effort you have been putting into the
Postgresql development. It is a great system. It performs well and with
the exception of a few little annoyances is a great competitor to Mysql
or Oracle!

This particular bug isn't a show stopper; I could have easily found a
way around it if I wanted to. Instead I decided to fall back to 8.0.3
since this will be fixed hopefully in 8.0.5. But it did make me think
of something else.

I would like to make a suggestion, if you don't mind. I don't mind
running the bleeding edge of things, and if you go to the gentoo bugs
you will see quite a few posted by me. My suggestion - and it might be
simply due to my not knowing where to look - is perhaps there should be
a simple way to find the bugs that are still outstanding or when they
resolved or how. On bugs.gentoo.org I can type in CUPS for example and
find out everything - resolved, past and present and outstanding, bugs
related to cups. I can find nothing on the postgresql site.

Yea, that is a good idea. If you look at the release notes the fixes we
usually do for minor releases are so small there is no need to report
them before the minor release. This is kind of a rare case.

Those bug dbs are great for tracking stuff, but getting stuff in there
and keeping it managed is pretty hard.

-- 
  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

#12

Michael Meskes

meskes@postgresql.org

about 20 years ago

In reply to: Bruce Momjian (#5)

Re: BUG #1962: ECPG and VARCHAR

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!

#13

Michael Meskes

meskes@postgresql.org

about 20 years ago

In reply to: C Wegrzyn (#3)

Re: BUG #1962: ECPG and VARCHAR

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!

#14

C Wegrzyn

lists@garbagedump.com

about 20 years ago

In reply to: Michael Meskes (#13)

Re: BUG #1962: ECPG and VARCHAR

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:

Show quoted text

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

#15

Michael Meskes

meskes@postgresql.org

about 20 years ago

In reply to: C Wegrzyn (#14)

Re: BUG #1962: ECPG and VARCHAR

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?