ECPG: inconsistent behavior with the document in “GET/SET DESCRIPTOR.”
Hi,
While using ECPG and its SQL descriptor, I found an inconsistency
between the document and the actual behavior.
According to the manual, it states that multiple header items can be specified.
https://www.postgresql.org/docs/current/ecpg-sql-get-descriptor.html
```
GET DESCRIPTOR descriptor_name :cvariable = descriptor_header_item [, ... ]
GET DESCRIPTOR descriptor_name VALUE column_number :cvariable = descriptor_item [, ... ]
```
So following embedded SQL should be accepted.
Actually, the compiler says OK.
However, the output source cannot be compiled.
Embedded SQL:
```
EXEC SQL GET DESCRIPTOR d :desc_count1 = count, :desc_count2 = count;
```
Precompiled result:
```
{ ECPGget_desc_header(__LINE__, "d", &(desc_count2desc_count1));
```
Reported error by the compiler:
```
bytea.pgc: In function 'main':
bytea.pgc:123:48: error: 'desc_count2desc_count1' undeclared (first use in this function)
123 | exec sql get descriptor d :desc_count1 = count, :desc_count2 = count;
| ^~~~~~~~~~~~~~~~~~~~~~
bytea.pgc:123:48: note: each undeclared identifier is reported only once for each function it appears in
```
According to my analysis, the parser can accept multiple headers,
but the output function cannot.
See ECPGGetDescHeaderItems and output_get_descr_header().
Therefore, it is thought that the variables were incorrectly concatenated,
resulting in an error.
I feel even if multiple header items cannot be specified,
invalid syntax should be detected by the precompiler, not the compiler.
Attached patch fixes both parser and the documentation.
After applying the patch, the above example can detect the invalid syntax
by the precompiler anymore.
```
bytea.pgc:123: ERROR: syntax error at or near ","
```
SET DESCRIPTOR also has the same issue, thus the patch fixes both.
I'm looking forward to your comments.
Regards,
Masashi Kamura
Fujitsu Limited
Attachments:
0001-ECPG-Reject-multiple-headers-in-GET-SET-DESCRIPTOR-a.patchapplication/octet-stream; name=0001-ECPG-Reject-multiple-headers-in-GET-SET-DESCRIPTOR-a.patchDownload+4-13
Dear Kamura-san,
Embedded SQL:
```
EXEC SQL GET DESCRIPTOR d :desc_count1 = count, :desc_count2 = count;
```Precompiled result:
```
{ ECPGget_desc_header(__LINE__, "d", &(desc_count2desc_count1));
```Reported error by the compiler:
```
bytea.pgc: In function 'main':bytea.pgc:123:48: error: 'desc_count2desc_count1' undeclared (first use in this
function)
Good catch, agreed that current result should be fixed.
According to my analysis, the parser can accept multiple headers,
but the output function cannot.
See ECPGGetDescHeaderItems and output_get_descr_header().
Therefore, it is thought that the variables were incorrectly concatenated,
resulting in an error.I feel even if multiple header items cannot be specified,
invalid syntax should be detected by the precompiler, not the compiler.
Attached patch fixes both parser and the documentation.
After applying the patch, the above example can detect the invalid syntax
by the precompiler anymore.
IIUC, there is another approach, allowing to specify multiple COUNT clause
in the SET/GET DESCRIPTOR. E.g.,
```
EXEC SQL GET DESCRIPTOR d :desc_count1 = count, :desc_count2 = count;
-> set COUNT value to desc_count1 and desc_count2.
```
Do you have theory which one is better?
Best regards,
Hayato Kuroda
FUJITSU LIMITED
Hi,
I was able to reproduce this issue.
The precompiler accepts:
EXEC SQL GET DESCRIPTOR d :desc_count1 = count, :desc_count2 = count;
but generates invalid C code with concatenated variables, which fails at
compile time.
After applying the patch and rebuilding ecpg, the same statement is now
rejected during preprocessing with a syntax error. So the patch works as
expected.
Thanks for the fix.
Regards,
Lakshmi G
Dear Lakshmi,
After applying the patch and rebuilding ecpg, the same statement is now rejected
during preprocessing with a syntax error. So the patch works as expected.
His patch may work well, but I'm unclear whether it's the correct way to fix.
See my question [1]/messages/by-id/OS9PR01MB12149D090EDD1D8D70770DED7F5232@OS9PR01MB12149.jpnprd01.prod.outlook.com:
```
IIUC, there is another approach, allowing to specify multiple COUNT clause
in the SET/GET DESCRIPTOR. E.g.,
```
We may have to follow SQL standard or other precompilers like Pro*C.
(Not sure we should spend the effort for the investigation though)
[1]: /messages/by-id/OS9PR01MB12149D090EDD1D8D70770DED7F5232@OS9PR01MB12149.jpnprd01.prod.outlook.com
Best regards,
Hayato Kuroda
FUJITSU LIMITED
Hi Lakshmi,
Thanks for confirming that the issue can be reproduced.
Regards,
Masashi Kamura
Fujitsu Limited
From: lakshmi <lakshmigcdac@gmail.com>
Sent: Monday, April 20, 2026 4:19 PM
To: Kuroda, Hayato/黒田 隼人 <kuroda.hayato@fujitsu.com>
Cc: Kamura, Masashi/嘉村 雅志 <kamura.masashi@fujitsu.com>; pgsql-hackers@postgresql.org
Subject: Re: ECPG: inconsistent behavior with the document in “GET/SET DESCRIPTOR.”
Hi,
I was able to reproduce this issue.
The precompiler accepts:
EXEC SQL GET DESCRIPTOR d :desc_count1 = count, :desc_count2 = count;
but generates invalid C code with concatenated variables, which fails at compile time.
After applying the patch and rebuilding ecpg, the same statement is now rejected during preprocessing with a syntax error. So the patch works as expected.
Thanks for the fix.
Regards,
Lakshmi G
Hi,
Thanks for the clarification.
from my testing, the current implementation generates invalid code when
multiple header assignments are used, so rejecting the syntax avoids the
issue for now.
That said, supporting multiple COUNT assignments could be useful, but it
would need changes in the code generation. It might be worth checking how
this is handled in the SQL standard or other precompilers.
Regards,
Lakshmi G
On Tue, Apr 21, 2026 at 1:20 PM Hayato Kuroda (Fujitsu) <
kuroda.hayato@fujitsu.com> wrote:
Show quoted text
Dear Lakshmi,
After applying the patch and rebuilding ecpg, the same statement is now
rejected
during preprocessing with a syntax error. So the patch works as expected.
His patch may work well, but I'm unclear whether it's the correct way to
fix.
See my question [1]:```
IIUC, there is another approach, allowing to specify multiple COUNT clause
in the SET/GET DESCRIPTOR. E.g.,
```We may have to follow SQL standard or other precompilers like Pro*C.
(Not sure we should spend the effort for the investigation though)[1]:
/messages/by-id/OS9PR01MB12149D090EDD1D8D70770DED7F5232@OS9PR01MB12149.jpnprd01.prod.outlook.comBest regards,
Hayato Kuroda
FUJITSU LIMITED
On Tue, Apr 21, 2026 at 5:28 PM lakshmi <lakshmigcdac@gmail.com> wrote:
Show quoted text
Hi,
I tried modifying the code generation to handle multiple variables.
Passing multiple variables in a single call (like &var1, &var2) doesn’t
work, since ECPGget_desc_header currently accepts only one variable.Looking at the existing code and tests, it seems the expected approach is
to call ECPGget_desc_header separately for each variable.So supporting multiple assignments would likely mean generating multiple
function calls instead of a single one.Regards,
Lakshmi G
Hi,
Syntax rules in the SQL standard do not appear to include any restrictions on specifying COUNT multiple times.
However, since the behavior when COUNT is specified multiple times in SET DESCRIPTOR is not also defined, I consider this to be undefined behavior.
In Oracle's Pro*C, COUNT can be specified only once.
Specifying it multiple times results in a syntax error.
This issue has been occurring from PG14 to PG18, but no one has pointed it out until now.
For the reasons above, I would like to proceed with the policy of treating this as a syntax error.
Regards,
Masashi Kamura
Fujitsu Limited
Dear Kamura-san,
For the reasons above, I would like to proceed with the policy of treating
this as a syntax error.
Make sense, so the v1 patch is usable as-is. It looks good to me.
Best regards,
Hayato Kuroda
FUJITSU LIMITED
Hi,
Thanks for the detailed explanation.
On Fri, Apr 24, 2026 at 10:24 AM Hayato Kuroda (Fujitsu) <
kuroda.hayato@fujitsu.com> wrote:
Dear Kamura-san,
For the reasons above, I would like to proceed with the policy of
treating
this as a syntax error.
Make sense, so the v1 patch is usable as-is. It looks good to me.
Handling this as a syntax error seems like a reasonable and consistent
approach, especially given the undefined behavior and alignment with other
systems like Pro*C.
The proposed patch looks good to me.
Regards,
Lakshmi G
Hi hackers,
Overall: The author found the case pre-compilation could succeed but the actual
compilation would fail, with SET/GET DESCRIPTOR. This patch tries to detect the
pre-compilation phase and raise a failure. Based on the SQL standard/other
DBMSs/history, it's not meaningful to allow the statement.
This does not contain tests because we cannot compile such a test program in the
first place.
I marked the thread "Ready for Committer".
Best regards,
Hayato Kuroda
FUJITSU LIMITED
On Mon, Apr 27, 2026 at 11:39 AM Hayato Kuroda (Fujitsu)
<kuroda.hayato@fujitsu.com> wrote:
Hi hackers,
Overall: The author found the case pre-compilation could succeed but the actual
compilation would fail, with SET/GET DESCRIPTOR. This patch tries to detect the
pre-compilation phase and raise a failure.
The patch looks good to me.
Barring any objections, I'm thinking to commit it.
Based on the SQL standard/other
DBMSs/history, it's not meaningful to allow the statement.
This does not contain tests because we cannot compile such a test program in the
first place.
I'm not sure this case warrants regression tests, but if we need them,
the attached patch adds them.
Regards,
--
Fujii Masao
Attachments:
v1-0001-Add-regression-tests-to-verify-that-duplicate-COU.patchapplication/octet-stream; name=v1-0001-Add-regression-tests-to-verify-that-duplicate-COU.patchDownload+39-1
Dear Fujii-san,
Overall: The author found the case pre-compilation could succeed but the actual
compilation would fail, with SET/GET DESCRIPTOR. This patch tries to detectthe
pre-compilation phase and raise a failure.
The patch looks good to me.
Barring any objections, I'm thinking to commit it.
Thanks!
Based on the SQL standard/other
DBMSs/history, it's not meaningful to allow the statement.
This does not contain tests because we cannot compile such a test program inthe
first place.
I'm not sure this case warrants regression tests, but if we need them,
the attached patch adds them.
Oh, I didn't recognized that we had TAP tests to detect error/warnings by the pre compiler.
I do not have strong opinions for it.
Best regards,
Hayato Kuroda
FUJITSU LIMITED
On Fri, May 29, 2026 at 12:44 PM Hayato Kuroda (Fujitsu)
<kuroda.hayato@fujitsu.com> wrote:
Oh, I didn't recognized that we had TAP tests to detect error/warnings by the pre compiler.
I do not have strong opinions for it.
IMO it feels a bit odd to add a test specifically for multiple items in
GET/SET DESCRIPTOR causing a syntax error, given that there are many
other unsupported syntax cases that we do not test. So I'm thinking not
to include that test.
Masashi-san,
Do you think this fix should be backpatched to all supported versions?
If so, could you prepare patches for the older branches?
Regards,
--
Fujii Masao
Hi Fujii-san,
Do you think this fix should be backpatched to all supported versions?
I think this change should be backported to prevent different behavior between versions.
If so, could you prepare patches for the older branches?
Patches for each version are attached.
Regards,
Masashi Kamura
Fujitsu Limited
Attachments:
PG14-0001-ECPG-Reject-multiple-headers-in-GET-SET-DESCRIPTOR-a.patchapplication/octet-stream; name=PG14-0001-ECPG-Reject-multiple-headers-in-GET-SET-DESCRIPTOR-a.patchDownload+4-13
PG15-0001-ECPG-Reject-multiple-headers-in-GET-SET-DESCRIPTOR-a.patchapplication/octet-stream; name=PG15-0001-ECPG-Reject-multiple-headers-in-GET-SET-DESCRIPTOR-a.patchDownload+4-13
PG16-0001-ECPG-Reject-multiple-headers-in-GET-SET-DESCRIPTOR-a.patchapplication/octet-stream; name=PG16-0001-ECPG-Reject-multiple-headers-in-GET-SET-DESCRIPTOR-a.patchDownload+4-13
PG17-0001-ECPG-Reject-multiple-headers-in-GET-SET-DESCRIPTOR-a.patchapplication/octet-stream; name=PG17-0001-ECPG-Reject-multiple-headers-in-GET-SET-DESCRIPTOR-a.patchDownload+4-13
PG18-0001-ECPG-Reject-multiple-headers-in-GET-SET-DESCRIPTOR-a.patchapplication/octet-stream; name=PG18-0001-ECPG-Reject-multiple-headers-in-GET-SET-DESCRIPTOR-a.patchDownload+4-13
On Fri, Jun 5, 2026 at 6:26 PM Masashi Kamura (Fujitsu)
<kamura.masashi@fujitsu.com> wrote:
Hi Fujii-san,
Do you think this fix should be backpatched to all supported versions?
I think this change should be backported to prevent different behavior between versions.
If so, could you prepare patches for the older branches?
Patches for each version are attached.
Thanks for the patches! I've pushed them.
Regards,
--
Fujii Masao