Thread: using arrays within structure in ECPG
Hi,
I tried using integer array within a structure array in ECPG code. But it resulted in some garbage values being printed from the table. Here are the details,
The ECPG program is attached (array_test.pgc). It tries to read the contents of table emp, whose structure and contents are as follows
postgres=# \d+ emp
Table "public.emp"
Column | Type | Modifiers | Storage | Stats target | Description
---------+-------------------+-----------+----------+--------------+-------------
empno | numeric(4,0) | | main | |
ename | character varying | | extended | |
job | character varying | | extended | |
arr_col | integer[] | | extended | |
Has OIDs: no
postgres=# select * from emp;
empno | ename | job | arr_col
-------+--------+---------+------------
7900 | JAMES | CLERK | {1,2,7900}
7902 | FORD | ANALYST | {1,2,7902}
7934 | MILLER | CLERK | {1,2,7934}
(3 rows)
postgres=# \d+ emp
Table "public.emp"
Column | Type | Modifiers | Storage | Stats target | Description
---------+-------------------+-----------+----------+--------------+-------------
empno | numeric(4,0) | | main | |
ename | character varying | | extended | |
job | character varying | | extended | |
arr_col | integer[] | | extended | |
Has OIDs: no
postgres=# select * from emp;
empno | ename | job | arr_col
-------+--------+---------+------------
7900 | JAMES | CLERK | {1,2,7900}
7902 | FORD | ANALYST | {1,2,7902}
7934 | MILLER | CLERK | {1,2,7934}
(3 rows)
You will notice that the last element of the arr_col array is same as the empno of that row.
The ECPG program tries to read the rows using FETCH in a structure emp defined as
15 struct employee {
16 int empno;
17 char ename[11];
18 char job[15];
19 int arr_col[3];
20 };
15 struct employee {
16 int empno;
17 char ename[11];
18 char job[15];
19 int arr_col[3];
20 };
and then print the read contents as
39 /* Print members of the structure. */
40 for ( i = 0 ;i < 3; i++){
41 printf("empno=%d, ename=%s, job=%s, arr_col[2]=%d\n", emp[i].empno, emp[i].ename, emp[i].job, emp[i].arr_col[2]);
42
43 }
39 /* Print members of the structure. */
40 for ( i = 0 ;i < 3; i++){
41 printf("empno=%d, ename=%s, job=%s, arr_col[2]=%d\n", emp[i].empno, emp[i].ename, emp[i].job, emp[i].arr_col[2]);
42
43 }
But garbage values are printed
[ashutosh@ubuntu repro]./array_test
+++++++++++++++++++++++++++++++++++++++++++++++
empno=7900, ename=JAMES, job=CLERK, arr_col[2]=1
empno=2, ename=�, job=ANALYST, arr_col[2]=32767
empno=7934, ename=MILLER, job=CLERK, arr_col[2]=1719202336
[ashutosh@ubuntu repro]./array_test
+++++++++++++++++++++++++++++++++++++++++++++++
empno=7900, ename=JAMES, job=CLERK, arr_col[2]=1
empno=2, ename=�, job=ANALYST, arr_col[2]=32767
empno=7934, ename=MILLER, job=CLERK, arr_col[2]=1719202336
Here are steps I have used to compile the ECPG program
[ashutosh@ubuntu repro]make array_test
ecpg -c -I/work/pg_head/build/include array_test.pgc
cc -I/work/pg_head/build/include -g -c -o array_test.o array_test.c
cc -g array_test.o -L/work/pg_head/build/lib -lecpg -lpq -o array_test
rm array_test.o array_test.c
[ashutosh@ubuntu repro]make array_test
ecpg -c -I/work/pg_head/build/include array_test.pgc
cc -I/work/pg_head/build/include -g -c -o array_test.o array_test.c
cc -g array_test.o -L/work/pg_head/build/lib -lecpg -lpq -o array_test
rm array_test.o array_test.c
where /work/pg_head/build is the directory containing the postgresql build (essentially argument to the --prefix option to configure).
The programs compiles and links fine.
Without the arr_col member, the program works fine. So, it seems to be a problem with array within structure array.
In array_test.c I see that the ECPGdo statement corresponding to the FETCH command is as follows
87 /* Fetch multiple columns into one structure. */
88 { ECPGdo(__LINE__, 0, 1, NULL, 0, ECPGst_normal, "fetch 3 from cur1", ECPGt_EOIT,
89 ECPGt_int,&(emp->empno),(long)1,(long)14,sizeof( struct employee ),
90 ECPGt_NO_INDICATOR, NULL , 0L, 0L, 0L,
91 ECPGt_char,&(emp->ename),(long)11,(long)14,sizeof( struct employee ),
92 ECPGt_NO_INDICATOR, NULL , 0L, 0L, 0L,
93 ECPGt_char,&(emp->job),(long)15,(long)14,sizeof( struct employee ),
94 ECPGt_NO_INDICATOR, NULL , 0L, 0L, 0L,
95 ECPGt_int,(emp->arr_col),(long)1,(long)3,sizeof(int),
96 ECPGt_NO_INDICATOR, NULL , 0L, 0L, 0L, ECPGt_EORT);
87 /* Fetch multiple columns into one structure. */
88 { ECPGdo(__LINE__, 0, 1, NULL, 0, ECPGst_normal, "fetch 3 from cur1", ECPGt_EOIT,
89 ECPGt_int,&(emp->empno),(long)1,(long)14,sizeof( struct employee ),
90 ECPGt_NO_INDICATOR, NULL , 0L, 0L, 0L,
91 ECPGt_char,&(emp->ename),(long)11,(long)14,sizeof( struct employee ),
92 ECPGt_NO_INDICATOR, NULL , 0L, 0L, 0L,
93 ECPGt_char,&(emp->job),(long)15,(long)14,sizeof( struct employee ),
94 ECPGt_NO_INDICATOR, NULL , 0L, 0L, 0L,
95 ECPGt_int,(emp->arr_col),(long)1,(long)3,sizeof(int),
96 ECPGt_NO_INDICATOR, NULL , 0L, 0L, 0L, ECPGt_EORT);
For all the members of struct employee, except arr_col, the size of array is set to 14 and next member offset is set of sizeof (struct employee). But for arr_col they are set to 3 and sizeof(int) resp. So, for the next row onwards, the calculated offset of arr_col member would not coincide with the real arr_col member's address.
Am I missing something here?
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
Attachment
2014-03-24 07:22 keltezéssel, Ashutosh Bapat írta:
Hi,I tried using integer array within a structure array in ECPG code. But it resulted in some garbage values being printed from the table. Here are the details,The ECPG program is attached (array_test.pgc). It tries to read the contents of table emp, whose structure and contents are as follows
postgres=# \d+ emp
Table "public.emp"
Column | Type | Modifiers | Storage | Stats target | Description
---------+-------------------+-----------+----------+--------------+-------------
empno | numeric(4,0) | | main | |
ename | character varying | | extended | |
job | character varying | | extended | |
arr_col | integer[] | | extended | |
Has OIDs: no
postgres=# select * from emp;
empno | ename | job | arr_col
-------+--------+---------+------------
7900 | JAMES | CLERK | {1,2,7900}
7902 | FORD | ANALYST | {1,2,7902}
7934 | MILLER | CLERK | {1,2,7934}
(3 rows)You will notice that the last element of the arr_col array is same as the empno of that row.The ECPG program tries to read the rows using FETCH in a structure emp defined as
15 struct employee {
16 int empno;
17 char ename[11];
18 char job[15];
19 int arr_col[3];
20 };and then print the read contents as
39 /* Print members of the structure. */
40 for ( i = 0 ;i < 3; i++){
41 printf("empno=%d, ename=%s, job=%s, arr_col[2]=%d\n", emp[i].empno, emp[i].ename, emp[i].job, emp[i].arr_col[2]);
42
43 }But garbage values are printed
[ashutosh@ubuntu repro]./array_test
+++++++++++++++++++++++++++++++++++++++++++++++
empno=7900, ename=JAMES, job=CLERK, arr_col[2]=1
empno=2, ename=�, job=ANALYST, arr_col[2]=32767
empno=7934, ename=MILLER, job=CLERK, arr_col[2]=1719202336Here are steps I have used to compile the ECPG program
[ashutosh@ubuntu repro]make array_test
ecpg -c -I/work/pg_head/build/include array_test.pgc
cc -I/work/pg_head/build/include -g -c -o array_test.o array_test.c
cc -g array_test.o -L/work/pg_head/build/lib -lecpg -lpq -o array_test
rm array_test.o array_test.cwhere /work/pg_head/build is the directory containing the postgresql build (essentially argument to the --prefix option to configure).The programs compiles and links fine.Without the arr_col member, the program works fine. So, it seems to be a problem with array within structure array.In array_test.c I see that the ECPGdo statement corresponding to the FETCH command is as follows
87 /* Fetch multiple columns into one structure. */
88 { ECPGdo(__LINE__, 0, 1, NULL, 0, ECPGst_normal, "fetch 3 from cur1", ECPGt_EOIT,
89 ECPGt_int,&(emp->empno),(long)1,(long)14,sizeof( struct employee ),
90 ECPGt_NO_INDICATOR, NULL , 0L, 0L, 0L,
91 ECPGt_char,&(emp->ename),(long)11,(long)14,sizeof( struct employee ),
92 ECPGt_NO_INDICATOR, NULL , 0L, 0L, 0L,
93 ECPGt_char,&(emp->job),(long)15,(long)14,sizeof( struct employee ),
94 ECPGt_NO_INDICATOR, NULL , 0L, 0L, 0L,
95 ECPGt_int,(emp->arr_col),(long)1,(long)3,sizeof(int),
96 ECPGt_NO_INDICATOR, NULL , 0L, 0L, 0L, ECPGt_EORT);For all the members of struct employee, except arr_col, the size of array is set to 14 and next member offset is set of sizeof (struct employee). But for arr_col they are set to 3 and sizeof(int) resp. So, for the next row onwards, the calculated offset of arr_col member would not coincide with the real arr_col member's address.Am I missing something here?
ECPG (I think intentionally) doesn't interpret or parse array fields.
You need to pass a character array and parse the contents by yourself.
Best regards,
Zoltán Böszörményi
--Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
On Mon, Mar 24, 2014 at 3:40 PM, Boszormenyi Zoltan <zboszor@pr.hu> wrote:
2014-03-24 07:22 keltezéssel, Ashutosh Bapat írta:ECPG (I think intentionally) doesn't interpret or parse array fields.Hi,I tried using integer array within a structure array in ECPG code. But it resulted in some garbage values being printed from the table. Here are the details,The ECPG program is attached (array_test.pgc). It tries to read the contents of table emp, whose structure and contents are as follows
postgres=# \d+ emp
Table "public.emp"
Column | Type | Modifiers | Storage | Stats target | Description
---------+-------------------+-----------+----------+--------------+-------------
empno | numeric(4,0) | | main | |
ename | character varying | | extended | |
job | character varying | | extended | |
arr_col | integer[] | | extended | |
Has OIDs: no
postgres=# select * from emp;
empno | ename | job | arr_col
-------+--------+---------+------------
7900 | JAMES | CLERK | {1,2,7900}
7902 | FORD | ANALYST | {1,2,7902}
7934 | MILLER | CLERK | {1,2,7934}
(3 rows)You will notice that the last element of the arr_col array is same as the empno of that row.The ECPG program tries to read the rows using FETCH in a structure emp defined as
15 struct employee {
16 int empno;
17 char ename[11];
18 char job[15];
19 int arr_col[3];
20 };and then print the read contents as
39 /* Print members of the structure. */
40 for ( i = 0 ;i < 3; i++){
41 printf("empno=%d, ename=%s, job=%s, arr_col[2]=%d\n", emp[i].empno, emp[i].ename, emp[i].job, emp[i].arr_col[2]);
42
43 }But garbage values are printed
[ashutosh@ubuntu repro]./array_test
+++++++++++++++++++++++++++++++++++++++++++++++
empno=7900, ename=JAMES, job=CLERK, arr_col[2]=1
empno=2, ename=� , job=ANALYST, arr_col[2]=32767
empno=7934, ename=MILLER, job=CLERK, arr_col[2]=1719202336Here are steps I have used to compile the ECPG program
[ashutosh@ubuntu repro]make array_test
ecpg -c -I/work/pg_head/build/include array_test.pgc
cc -I/work/pg_head/build/include -g -c -o array_test.o array_test.c
cc -g array_test.o -L/work/pg_head/build/lib -lecpg -lpq -o array_test
rm array_test.o array_test.cwhere /work/pg_head/build is the directory containing the postgresql build (essentially argument to the --prefix option to configure).The programs compiles and links fine.Without the arr_col member, the program works fine. So, it seems to be a problem with array within structure array.In array_test.c I see that the ECPGdo statement corresponding to the FETCH command is as follows
87 /* Fetch multiple columns into one structure. */
88 { ECPGdo(__LINE__, 0, 1, NULL, 0, ECPGst_normal, "fetch 3 from cur1", ECPGt_EOIT,
89 ECPGt_int,&(emp->empno),(long)1,(long)14,sizeof( struct employee ),
90 ECPGt_NO_INDICATOR, NULL , 0L, 0L, 0L,
91 ECPGt_char,&(emp->ename),(long)11,(long)14,sizeof( struct employee ),
92 ECPGt_NO_INDICATOR, NULL , 0L, 0L, 0L,
93 ECPGt_char,&(emp->job),(long)15,(long)14,sizeof( struct employee ),
94 ECPGt_NO_INDICATOR, NULL , 0L, 0L, 0L,
95 ECPGt_int,(emp->arr_col),(long)1,(long)3,sizeof(int),
96 ECPGt_NO_INDICATOR, NULL , 0L, 0L, 0L, ECPGt_EORT);For all the members of struct employee, except arr_col, the size of array is set to 14 and next member offset is set of sizeof (struct employee). But for arr_col they are set to 3 and sizeof(int) resp. So, for the next row onwards, the calculated offset of arr_col member would not coincide with the real arr_col member's address.Am I missing something here?
You need to pass a character array and parse the contents by yourself.
That doesn't seem to be the case with bare arrays (not included in anything else). I added following lines to the program attached in my first mail, and they worked perfectly fine.
47 /* Test only arrays */
48 EXEC SQL DECLARE cur2 CURSOR FOR select arr_col from emp;
49
50 EXEC SQL OPEN cur2;
51
52 EXEC SQL FETCH 1 FROM cur2 into :emp[0].arr_col;
53
54 printf("\n+++++++++++++++++++++++++++++++++++++++++++++++\n");
55
56 /* Print members of the array fetched. */
57 for ( i = 0 ;i < 3; i++)
58 {
59 printf("arr_col[%d] = %d\n", i, emp[0].arr_col[i]);
60 }
61 EXEC SQL CLOSE cur2;
47 /* Test only arrays */
48 EXEC SQL DECLARE cur2 CURSOR FOR select arr_col from emp;
49
50 EXEC SQL OPEN cur2;
51
52 EXEC SQL FETCH 1 FROM cur2 into :emp[0].arr_col;
53
54 printf("\n+++++++++++++++++++++++++++++++++++++++++++++++\n");
55
56 /* Print members of the array fetched. */
57 for ( i = 0 ;i < 3; i++)
58 {
59 printf("arr_col[%d] = %d\n", i, emp[0].arr_col[i]);
60 }
61 EXEC SQL CLOSE cur2;
Anyway, if that's a restriction, shouldn't there be an error during compilation?
Best regards,
Zoltán Böszörményi--Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
On Mon, Mar 24, 2014 at 11:52:30AM +0530, Ashutosh Bapat wrote: > For all the members of struct employee, except arr_col, the size of array > is set to 14 and next member offset is set of sizeof (struct employee). But > for arr_col they are set to 3 and sizeof(int) resp. So, for the next row > onwards, the calculated offset of arr_col member would not coincide with > the real arr_col member's address. > > Am I missing something here? No, this looks like a bug to me. I haven't had time to look into the source codebut the offset definitely is off. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Hi MIchael,
I tried to fix the offset problem. PFA the patch. It does solve the problem of setting wrong offset in ECPGdo() call.But then there is problem of interpreting the result from server as an array within array of structure. The problem is there is in ecpg_get_data(). This function can not understand that the "field" is an array of integers (or for that matter array of anything) and store all the values in contiguous memory at the given address.
On Thu, Mar 27, 2014 at 11:05 PM, Michael Meskes <meskes@postgresql.org> wrote:
On Mon, Mar 24, 2014 at 11:52:30AM +0530, Ashutosh Bapat wrote:No, this looks like a bug to me. I haven't had time to look into the source codebut the offset definitely is off.
> For all the members of struct employee, except arr_col, the size of array
> is set to 14 and next member offset is set of sizeof (struct employee). But
> for arr_col they are set to 3 and sizeof(int) resp. So, for the next row
> onwards, the calculated offset of arr_col member would not coincide with
> the real arr_col member's address.
>
> Am I missing something here?
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at gmail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
Attachment
Hi Ashutosh, > I tried to fix the offset problem. PFA the patch. It does solve the > problem of setting wrong offset in ECPGdo() call. Thanks, looks correct to me. > But then there is problem of interpreting the result from server as an > array within array of structure. The problem is there is in > ecpg_get_data(). This function can not understand that the "field" is an > array of integers (or for that matter array of anything) and store all > the values in contiguous memory at the given address. I guess I know where that comes from, without actually looking at the code, though. Nested arrays are not supported by ecpg and the precompiler spits out an error message, just check preproc/type.c. However, in your example you have the struct essantially sandwiched between the arrays and the (too) simple check in that file doesn't notice, but because the implementation is nevertheless lacking. I'm sorry, but this sounds like a missing feature bug. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
On Tue, Apr 1, 2014 at 11:50 AM, Michael Meskes <meskes@postgresql.org> wrote: > Hi Ashutosh, > >> I tried to fix the offset problem. PFA the patch. It does solve the >> problem of setting wrong offset in ECPGdo() call. > > Thanks, looks correct to me. > >> But then there is problem of interpreting the result from server as an >> array within array of structure. The problem is there is in >> ecpg_get_data(). This function can not understand that the "field" is an >> array of integers (or for that matter array of anything) and store all >> the values in contiguous memory at the given address. > > I guess I know where that comes from, without actually looking at the > code, though. Nested arrays are not supported by ecpg and the > precompiler spits out an error message, just check preproc/type.c. > However, in your example you have the struct essantially sandwiched > between the arrays and the (too) simple check in that file doesn't > notice, but because the implementation is nevertheless lacking. > > I'm sorry, but this sounds like a missing feature bug. Small aside: I've often wondered if the right long term approach is to abstract backend type code into a shared library that both the server and (optionally) the client would link with. That would make extending support to exotic types in ecpg much easier. merlin
<div dir="ltr">So, you are saying that we should try to catch such errors and report during pre-compile time. That's betterthan silently corrupting the data.<br /></div><div class="gmail_extra"><br /><br /><div class="gmail_quote"> On Tue,Apr 1, 2014 at 10:20 PM, Michael Meskes <span dir="ltr"><<a href="mailto:meskes@postgresql.org" target="_blank">meskes@postgresql.org</a>></span>wrote:<br /><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px#ccc solid;padding-left:1ex"> Hi Ashutosh,<br /><div class=""><br /> > I tried to fix the offset problem.PFA the patch. It does solve the<br /> > problem of setting wrong offset in ECPGdo() call.<br /><br /></div>Thanks,looks correct to me.<br /><div class=""><br /> > But then there is problem of interpreting the result fromserver as an<br /> > array within array of structure. The problem is there is in<br /> > ecpg_get_data(). Thisfunction can not understand that the "field" is an<br /> > array of integers (or for that matter array of anything)and store all<br /> > the values in contiguous memory at the given address.<br /><br /></div>I guess I know wherethat comes from, without actually looking at the<br /> code, though. Nested arrays are not supported by ecpg and the<br/> precompiler spits out an error message, just check preproc/type.c.<br /> However, in your example you have the structessantially sandwiched<br /> between the arrays and the (too) simple check in that file doesn't<br /> notice, but becausethe implementation is nevertheless lacking.<br /><br /> I'm sorry, but this sounds like a missing feature bug.<br/><div class="HOEnZb"><div class="h5"><br /> Michael<br /> --<br /> Michael Meskes<br /> Michael at Fam-Meskes dotDe, Michael at Meskes dot (De|Com|Net|Org)<br /> Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org<br/> Jabber: michael.meskes at gmail dot com<br /> VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL<br/></div></div></blockquote></div><br /><br clear="all" /><br />-- <br /><div dir="ltr">Best Wishes,<br />AshutoshBapat<br />EnterpriseDB Corporation<br />The Postgres Database Company<br /></div></div>
On Wed, Apr 02, 2014 at 09:33:15AM +0530, Ashutosh Bapat wrote: > So, you are saying that we should try to catch such errors and report > during pre-compile time. That's better than silently corrupting the data. Well, I think this goes without saying. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
I have one more doubt, regarding offsets.
In ECPGdump_a_simple() we have codeif (siz == NULL || strlen(siz) == 0 || strcmp(arrsize, "0") == 0 || strcmp(arrsize, "1") == 0)
fprintf(o, "\n\t%s,%s,(long)%s,(long)%s,%s, ", get_type(type), variable, varcharsize, arrsize, offset);
else
fprintf(o, "\n\t%s,%s,(long)%s,(long)%s,%s, ", get_type(type), variable, varcharsize, arrsize, siz);
On Wed, Apr 2, 2014 at 3:10 PM, Michael Meskes <meskes@postgresql.org> wrote:
On Wed, Apr 02, 2014 at 09:33:15AM +0530, Ashutosh Bapat wrote:Well, I think this goes without saying.
> So, you are saying that we should try to catch such errors and report
> during pre-compile time. That's better than silently corrupting the data.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at gmail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
On Wed, Apr 02, 2014 at 05:49:03PM +0530, Ashutosh Bapat wrote: > I have one more doubt, regarding offsets. > ... This is actually a very good question. Parts of this code are older than my work on ecpg, meaning they were already in version 0.1. It could very well be that with some changes over the years this test isn't needed anymore. The regression suite works without just nicely. To be honest, the whole type.c code needs a real rewrite to be better legible. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Hi Michael,
The problem of offsets seems to be universal. If there is a structure within structure. The offset to the members of inner structure should be the size of the outer structure and not size of inner structure. Applying this rule recursively, offset to the member of any nested structure, at whatever level of nesting it is, should be same as the size of the outermost structure. But the code as of now, is using the size of the immediate parent.
None of these problems are caught in the regression because, whatever tests I have seen are not fetching more than one tuple into such complex structure.The problem of offsets seems to be universal. If there is a structure within structure. The offset to the members of inner structure should be the size of the outer structure and not size of inner structure. Applying this rule recursively, offset to the member of any nested structure, at whatever level of nesting it is, should be same as the size of the outermost structure. But the code as of now, is using the size of the immediate parent.
On Tue, Apr 1, 2014 at 4:34 PM, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> wrote:
Hi MIchael,I tried to fix the offset problem. PFA the patch. It does solve the problem of setting wrong offset in ECPGdo() call.
But then there is problem of interpreting the result from server as an array within array of structure. The problem is there is in ecpg_get_data(). This function can not understand that the "field" is an array of integers (or for that matter array of anything) and store all the values in contiguous memory at the given address.On Thu, Mar 27, 2014 at 11:05 PM, Michael Meskes <meskes@postgresql.org> wrote:On Mon, Mar 24, 2014 at 11:52:30AM +0530, Ashutosh Bapat wrote:No, this looks like a bug to me. I haven't had time to look into the source codebut the offset definitely is off.
> For all the members of struct employee, except arr_col, the size of array
> is set to 14 and next member offset is set of sizeof (struct employee). But
> for arr_col they are set to 3 and sizeof(int) resp. So, for the next row
> onwards, the calculated offset of arr_col member would not coincide with
> the real arr_col member's address.
>
> Am I missing something here?
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at gmail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL--Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company