The server allows setting both in the same request, so there's no reason we shouldn't allow that.

It's confusing.

https://docs.oracle.com/cd/E11882_01/appdev.112/e25519/subprograms.htm#LNPLS

It's confusing.

https://docs.oracle.com/cd/E11882_01/appdev.112/e25519/subprograms.htm#LNPLS

The parameters defined in that document are more akin to function parameters, where you can refer to the same set of parameters either using their position or their name. In SQL++ named and positional parameters are entirely separate sets of parameters. Positional parameters are explicitly defined as such as they are included in the statement with a specific index, it doesn't have anything to do with their physical position in the statement.

You can also do things like SELECT $2 fieldA, $1 fieldB where the parameters must be given in the reverse order of where they appear in the statement, which are also somewhat confusing (and probably not a great idea) even without using named parameters.

My opinion is that we shouldn't prevent users from doing something that's supported by the query service. I think if there is a decision that named and positional parameters must not be mixed, that decision should be made by the query service with an appropriate error. The user experience of silently clearing parameters is not great.

Something that's come up in discussions is whether this could be a breaking change.

I can see two examples where there could be a risk of breaking change:

1. A statement that has both named and positional parameters, and the user is setting both named and positional params via the options. Instead of consistently getting an error, the query will now succeed. I think that's ok, and can be considered an "new feature" instead of a breaking change.
2. A query with statement that only has e.g. named parameters and the setter for positional parameters is called, followed by the setter for the named parameters, which will clear the positional parameters. So the SDK will only send a request with named parameters. Even if we make the change to send both the named and positional parameters here, this will not result in a different behaviour, as the query service ignores any extra named/positional parameters that don't appear in the statement.

So I don't think we'll end up with a breaking change here. Please let me know If there are any other examples where there is a breaking change that I missed, or if anyone disagrees with the above.