Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New "escapeSyntaxCallMode" connection property #1560

Merged
merged 1 commit into from Nov 26, 2019

Conversation

@gregn123
Copy link
Contributor

gregn123 commented Sep 5, 2019

The new "escapeSyntaxCallMode" connection property allows you to specify how the driver transforms JDBC escape call syntax into underlying SQL, for invoking stored procedures or functions. (backend >= 11).
The possible values of this property are: select, callIfNoReturn, or call
In escapeSyntaxCallMode=select mode (the default), the JDBC driver always uses a SELECT statement (allowing function invocation only).
In escapeSyntaxCallMode=callIfNoReturn mode, the JDBC driver uses a CALL statement (allowing procedure invocation) if there is no return parameter specified.
In escapeSyntaxCallMode=call mode, the JDBC driver always uses a CALL statement (allowing procedure invocation only).

Without the addition of this new connection property, PGJDBC will always use a SELECT statement for JDBC escape call syntax, which results in the following error if an attempt is made to invoke a procedure:
ERROR: xxxx is a procedure Hint: To call a procedure, use CALL

@AppVeyorBot

This comment has been minimized.

Copy link

AppVeyorBot commented Sep 5, 2019

@davecramer

This comment has been minimized.

Copy link
Member

davecramer commented Sep 5, 2019

Thanks for this. I think it would be useful to do an end to end test to test procedures.
Also there are 2 places where connection strings are documented; the README.md and https://jdbc.postgresql.org/documentation/head/connect.html#connection-parameters. These should reflect the new feature as well.

@gregn123

This comment has been minimized.

Copy link
Contributor Author

gregn123 commented Sep 6, 2019

Thanks, I'm working on those additional updates (and some corrections for Javadoc).

@gregn123 gregn123 force-pushed the gregn123:escape_syntax_call_mode_option branch from cd6f9cb to c3619c7 Sep 8, 2019
@AppVeyorBot

This comment has been minimized.

Copy link

AppVeyorBot commented Sep 8, 2019

@gregn123

This comment has been minimized.

Copy link
Contributor Author

gregn123 commented Sep 13, 2019

I may be wrong, but the failure reported in the Travis CI build doesn't seem to be related to the proposed changes in the PR (?). Could there be another reason for that failure?

@davecramer

This comment has been minimized.

Copy link
Member

davecramer commented Nov 25, 2019

@gregn123 sorry this has taken so long can you fix the conflict and I will push this.

@gregn123 gregn123 force-pushed the gregn123:escape_syntax_call_mode_option branch 2 times, most recently from 26e051c to a3fbc95 Nov 26, 2019
The "escapeSyntaxCallMode" connection property allows you to specify how the driver transforms
JDBC escape call syntax into underlying SQL, for invoking procedures and functions.
The possible values of this property are: select, callIfNoReturn, or call
In escapeSyntaxCallMode=select mode (the default), the driver always uses a SELECT statement
(allowing function invocation only).
In escapeSyntaxCallMode=callIfNoReturn mode, the driver uses a CALL statement (allowing
procedure invocation) if there is no return parameter specified, otherwise the driver uses a
SELECT statement.
In escapeSyntaxCallMode=call mode, the driver always uses a CALL statement (allowing procedure
invocation only).
Prior to the addition of this connection property, the driver always used a SELECT statement for
JDBC escape call syntax, which results in the following error when attempting to invoke a
procedure:
    ERROR: xxxx is a procedure  Hint: To call a procedure, use CALL
@gregn123 gregn123 force-pushed the gregn123:escape_syntax_call_mode_option branch from a3fbc95 to e1f7aea Nov 26, 2019
@AppVeyorBot

This comment has been minimized.

Copy link

AppVeyorBot commented Nov 26, 2019

@davecramer davecramer merged commit d755913 into pgjdbc:master Nov 26, 2019
2 checks passed
2 checks passed
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@davecramer davecramer mentioned this pull request Jan 3, 2020
0 of 1 task complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.