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 <[email protected]> wrote: > > I would think it would be, yes. The extent to which I have planned this so > far is zero. > > ________________________________ > From: Julian Hyde <[email protected]> > Sent: Friday, May 15, 2026 10:44 > To: [email protected] <[email protected]> > 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 <[email protected]> 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 <[email protected]> >>> 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. >>> >>>
