You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by Jerome Haltom <jh...@alethic.solutions> on 2026/05/15 14:56:07 UTC
Named Parameters
Is there any interest in the parser to introduce the concept of named parameters, or does it already exist somewhere? SqlDynamicParam right now is indexed. This maps pretty cleanly to JDBC, and also ODBC, but plenty of database types use named parameters now: @P1, etc.
I am trying to wrap Calcite in a ORM framework which currently completely loses track of the order of parameters it creates, since it expects the underlying database itself to support named parameters. So, I have two options of attack: fix that ORM framework, or find/add such a capability in Calcite.
Re: Named Parameters
Posted by Julian Hyde <jh...@gmail.com>.
Planning starts with a specification. Don’t worry about an implementation until we are at consensus.
> On May 15, 2026, at 8:45 AM, Jerome Haltom <jh...@alethic.solutions> wrote:
>
> I would think it would be, yes. The extent to which I have planned this so far is zero.
>
> ________________________________
> From: Julian Hyde <jh...@gmail.com>
> Sent: Friday, May 15, 2026 10:44
> To: dev@calcite.apache.org <de...@calcite.apache.org>
> Subject: Re: Named Parameters
>
> PS Does your proposal allow a parameter with the same name to occur more than once? I can see that that would be useful, but it might be tricky to ensure compatibility. So, address the problems in your proposal.
>
>> On May 15, 2026, at 8:41 AM, Julian Hyde <jh...@gmail.com> wrote:
>>
>> I would support it as long as it doesn’t break people who wish to continue to use regular parameters. Try to find a specification (syntax) used in several other databases. Describe how the named parameters could be described and bound via JDBC (or minimal extensions to it). Then log a jira case for further discussion.
>>
>>> On May 15, 2026, at 7:56 AM, Jerome Haltom <jh...@alethic.solutions> wrote:
>>>
>>> Is there any interest in the parser to introduce the concept of named parameters, or does it already exist somewhere? SqlDynamicParam right now is indexed. This maps pretty cleanly to JDBC, and also ODBC, but plenty of database types use named parameters now: @P1, etc.
>>>
>>> I am trying to wrap Calcite in a ORM framework which currently completely loses track of the order of parameters it creates, since it expects the underlying database itself to support named parameters. So, I have two options of attack: fix that ORM framework, or find/add such a capability in Calcite.
>>>
>>>
Re: Named Parameters
Posted by Jerome Haltom <jh...@alethic.solutions>.
I would think it would be, yes. The extent to which I have planned this so far is zero.
________________________________
From: Julian Hyde <jh...@gmail.com>
Sent: Friday, May 15, 2026 10:44
To: dev@calcite.apache.org <de...@calcite.apache.org>
Subject: Re: Named Parameters
PS Does your proposal allow a parameter with the same name to occur more than once? I can see that that would be useful, but it might be tricky to ensure compatibility. So, address the problems in your proposal.
> On May 15, 2026, at 8:41 AM, Julian Hyde <jh...@gmail.com> wrote:
>
> I would support it as long as it doesn’t break people who wish to continue to use regular parameters. Try to find a specification (syntax) used in several other databases. Describe how the named parameters could be described and bound via JDBC (or minimal extensions to it). Then log a jira case for further discussion.
>
>> On May 15, 2026, at 7:56 AM, Jerome Haltom <jh...@alethic.solutions> wrote:
>>
>> Is there any interest in the parser to introduce the concept of named parameters, or does it already exist somewhere? SqlDynamicParam right now is indexed. This maps pretty cleanly to JDBC, and also ODBC, but plenty of database types use named parameters now: @P1, etc.
>>
>> I am trying to wrap Calcite in a ORM framework which currently completely loses track of the order of parameters it creates, since it expects the underlying database itself to support named parameters. So, I have two options of attack: fix that ORM framework, or find/add such a capability in Calcite.
>>
>>
Re: Named Parameters
Posted by Julian Hyde <jh...@gmail.com>.
PS Does your proposal allow a parameter with the same name to occur more than once? I can see that that would be useful, but it might be tricky to ensure compatibility. So, address the problems in your proposal.
> On May 15, 2026, at 8:41 AM, Julian Hyde <jh...@gmail.com> wrote:
>
> I would support it as long as it doesn’t break people who wish to continue to use regular parameters. Try to find a specification (syntax) used in several other databases. Describe how the named parameters could be described and bound via JDBC (or minimal extensions to it). Then log a jira case for further discussion.
>
>> On May 15, 2026, at 7:56 AM, Jerome Haltom <jh...@alethic.solutions> wrote:
>>
>> Is there any interest in the parser to introduce the concept of named parameters, or does it already exist somewhere? SqlDynamicParam right now is indexed. This maps pretty cleanly to JDBC, and also ODBC, but plenty of database types use named parameters now: @P1, etc.
>>
>> I am trying to wrap Calcite in a ORM framework which currently completely loses track of the order of parameters it creates, since it expects the underlying database itself to support named parameters. So, I have two options of attack: fix that ORM framework, or find/add such a capability in Calcite.
>>
>>
Re: Named Parameters
Posted by Julian Hyde <jh...@gmail.com>.
I would support it as long as it doesn’t break people who wish to continue to use regular parameters. Try to find a specification (syntax) used in several other databases. Describe how the named parameters could be described and bound via JDBC (or minimal extensions to it). Then log a jira case for further discussion.
On May 15, 2026, at 7:56 AM, Jerome Haltom <jh...@alethic.solutions> wrote:
>
> Is there any interest in the parser to introduce the concept of named parameters, or does it already exist somewhere? SqlDynamicParam right now is indexed. This maps pretty cleanly to JDBC, and also ODBC, but plenty of database types use named parameters now: @P1, etc.
>
> I am trying to wrap Calcite in a ORM framework which currently completely loses track of the order of parameters it creates, since it expects the underlying database itself to support named parameters. So, I have two options of attack: fix that ORM framework, or find/add such a capability in Calcite.
>
>