Horton
Menu

Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. ecpg: Reject multiple header items in GET/SET DESCRIPTOR

  1. ECPG: inconsistent behavior with the document in “GET/SET DESCRIPTOR.”

    Masashi Kamura (Fujitsu) <kamura.masashi@fujitsu.com> — 2026-03-11T09:49:46Z

    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

  2. RE: ECPG: inconsistent behavior with the document in “GET/SET DESCRIPTOR.”

    Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com> — 2026-04-16T05:48:15Z

    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

  3. Re: ECPG: inconsistent behavior with the document in “GET/SET DESCRIPTOR.”

    lakshmi <lakshmigcdac@gmail.com> — 2026-04-20T07:18:48Z

    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

  4. RE: ECPG: inconsistent behavior with the document in “GET/SET DESCRIPTOR.”

    Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com> — 2026-04-21T07:50:17Z

    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]: https://www.postgresql.org/message-id/OS9PR01MB12149D090EDD1D8D70770DED7F5232%40OS9PR01MB12149.jpnprd01.prod.outlook.com

Best regards,
Hayato Kuroda
FUJITSU LIMITED

  5. RE: ECPG: inconsistent behavior with the document in “GET/SET DESCRIPTOR.”

    Masashi Kamura (Fujitsu) <kamura.masashi@fujitsu.com> — 2026-04-21T08:50:24Z

    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

  6. Re: ECPG: inconsistent behavior with the document in “GET/SET DESCRIPTOR.”

    lakshmi <lakshmigcdac@gmail.com> — 2026-04-21T11:58:19Z

    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:

> 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]:
> https://www.postgresql.org/message-id/OS9PR01MB12149D090EDD1D8D70770DED7F5232%40OS9PR01MB12149.jpnprd01.prod.outlook.com
>
> Best regards,
> Hayato Kuroda
> FUJITSU LIMITED
>
>

  7. Re: ECPG: inconsistent behavior with the document in “GET/SET DESCRIPTOR.”

    lakshmi <lakshmigcdac@gmail.com> — 2026-04-22T07:16:13Z

    On Tue, Apr 21, 2026 at 5:28 PM lakshmi <lakshmigcdac@gmail.com> wrote:

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

  8. RE: ECPG: inconsistent behavior with the document in “GET/SET DESCRIPTOR.”

    Masashi Kamura (Fujitsu) <kamura.masashi@fujitsu.com> — 2026-04-24T03:08:36Z

    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

  9. RE: ECPG: inconsistent behavior with the document in “GET/SET DESCRIPTOR.”

    Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com> — 2026-04-24T04:54:18Z

    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

  10. Re: ECPG: inconsistent behavior with the document in “GET/SET DESCRIPTOR.”

    lakshmi <lakshmigcdac@gmail.com> — 2026-04-24T07:18:41Z

    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

  11. RE: ECPG: inconsistent behavior with the document in “GET/SET DESCRIPTOR.”

    Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com> — 2026-04-27T02:39:42Z

    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

  12. Re: ECPG: inconsistent behavior with the document in “GET/SET DESCRIPTOR.”

    Fujii Masao <masao.fujii@gmail.com> — 2026-05-29T03:11:38Z

    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

  13. RE: ECPG: inconsistent behavior with the document in “GET/SET DESCRIPTOR.”

    Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com> — 2026-05-29T03:44:22Z

    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 detect
> the
> > 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 in
> the
> > 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

  14. Re: ECPG: inconsistent behavior with the document in “GET/SET DESCRIPTOR.”

    Fujii Masao <masao.fujii@gmail.com> — 2026-06-03T08:13:37Z

    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

  15. RE: ECPG: inconsistent behavior with the document in “GET/SET DESCRIPTOR.”

    Masashi Kamura (Fujitsu) <kamura.masashi@fujitsu.com> — 2026-06-05T09:26:01Z

    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

  16. Re: ECPG: inconsistent behavior with the document in “GET/SET DESCRIPTOR.”

    Fujii Masao <masao.fujii@gmail.com> — 2026-06-08T08:32:18Z

    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