Обсуждение: [BUGS] Parser failed to return an error
Linux roblaptop 4.9.0-1-amd64 #1 SMP Debian 4.9.2-2 (2017-01-12) x86_64 GNU/Linux I was running a query like:- SELECT TO_CHAR(my_date,'dd-mm-yyyy) FROM my_table; and I forgot to type the second single quotation mark at the end of the mask string. Under psql it just hung and I had to Ctrl-C to go back to a prompt and under JDBC it hung as well and EQ just said "error", as in a failure of some sort. I would have expected either a 42601 error or maybe a 03000 error to have been returned. If you need any further information, please let me know. Rob -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
On Thursday, February 2, 2017, rob stone <floriparob@gmail.com> wrote:
Linux roblaptop 4.9.0-1-amd64 #1 SMP Debian 4.9.2-2 (2017-01-12) x86_64
GNU/Linux
I was running a query like:-
SELECT TO_CHAR(my_date,'dd-mm-yyyy) FROM my_table;
and I forgot to type the second single quotation mark at the end of the
mask string.
Under psql it just hung and I had to Ctrl-C to go back to a prompt and
under JDBC it hung as well and EQ just said "error", as in a failure of
some sort.
I would have expected either a 42601 error or maybe a 03000 error to
have been returned.
At least in psql that isn't a query. It's a multi-line query fragment. The UI is waiting for you to enter more of the query and end the string literal that you've begun.
David J.
On Thu, Feb 2, 2017 at 11:14 AM, David G. Johnston <david.g.johnston@gmail.com> wrote:
On Thursday, February 2, 2017, rob stone <floriparob@gmail.com> wrote:
Linux roblaptop 4.9.0-1-amd64 #1 SMP Debian 4.9.2-2 (2017-01-12) x86_64
GNU/Linux
I was running a query like:-
SELECT TO_CHAR(my_date,'dd-mm-yyyy) FROM my_table;
and I forgot to type the second single quotation mark at the end of the
mask string.
Under psql it just hung and I had to Ctrl-C to go back to a prompt and
under JDBC it hung as well and EQ just said "error", as in a failure of
some sort.
I would have expected either a 42601 error or maybe a 03000 error to
have been returned.At least in psql that isn't a query. It's a multi-line query fragment. The UI is waiting for you to enter more of the query and end the string literal that you've begun.
Also, that is indicated by the change in prompt from => to '> (assuming you are using the default prompts).
That would seem to be bug in JDBC, though. Rob, can you provide a full example code?
What is "EQ"?
Cheers,
Jeff
> Linux roblaptop 4.9.0-1-amd64 #1 SMP Debian 4.9.2-2 (2017-01-12) x86_64 > GNU/Linux > > > I was running a query like:- > > SELECT TO_CHAR(my_date,'dd-mm-yyyy) FROM my_table; > > and I forgot to type the second single quotation mark at the end of the > mask string. > > Under psql it just hung and I had to Ctrl-C to go back to a prompt and > under JDBC it hung as well and EQ just said "error", as in a failure of > some sort. > > I would have expected either a 42601 error or maybe a 03000 error to > have been returned. > > > If you need any further information, please let me know. Sounds like psql application or JDBC specific behaviors (not sure expected ones though). I was able to confirm that the PostgreSQL backend correctly returns a 42601 error in this case by using "pgproto" (https://github.com/tatsuo-ishii/pgproto), which handles PostgreSQL frontend/backend protocol in low level. $ pgproto -f /tmp/p -d test FE=> Query(query="CREATE TABLE my_table(my_date date);") <= BE CommandComplete(CREATE TABLE) <= BE ReadyForQuery(I) FE=> Query(query="SELECT TO_CHAR(my_date,'dd-mm-yyyy) FROM my_table;") <= BE ErrorResponse(S ERROR V ERROR C 42601 M unterminated quoted string at or near "'dd-mm-yyyy) FROM my_table;" P 24 Fscan.l L 1086 R scanner_yyerror ) <= BE ReadyForQuery(I) FE=> Terminate The test data used: ------------------------------------------------- # Create table 'Q' "CREATE TABLE my_table(my_date date);" # Read reply from backend 'Y' # Issue the query in question 'Q' "SELECT TO_CHAR(my_date,'dd-mm-yyyy) FROM my_table;" # Read reply from backend 'Y' # Terminate session 'X' ------------------------------------------------- Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Sounds like psql application or JDBC specific behaviors (not sure
expected ones though).
Its quite expected in psql. If it didn't do this certain queries would be impossible to write and execute. As soon as you being a string psql just continually captures text into said string until you end the string. It gives hints that its doing this too. It won't send anything to the backend until the complete query is written - which is good since the backend isn't setup to deal with partial queries.
The OP just expected a higher level of artificial intelligence than what is worth coding into this kind of application.
David J.
Hello Jeff, On Fri, 2017-02-03 at 13:10 -0800, Jeff Janes wrote: > On Thu, Feb 2, 2017 at 11:14 AM, David G. Johnston <david.g.johnston@ > gmail.com> wrote: > > On Thursday, February 2, 2017, rob stone <floriparob@gmail.com> > > wrote: > Also, that is indicated by the change in prompt from => to '> > (assuming you are using the default prompts). > > That would seem to be bug in JDBC, though. Rob, can you provide a > full example code? > What is "EQ"? > > Cheers, > > Jeff "EQ" is a program called ExecuteQuery. You can download the deb package from www.executequery.org. I use it all the time. It is written in Java. I was testing a fairly verbose query and finding my typo took ages. Usually running a statement using EQ and there is an error, it gives you the character position, so you can quickly find your mistake and try again. Instead of reproducing the entire query I posted just the part causing the problem. It appears Tatsuo Ishii has investigated further and illustrated better as to what happens when the to_char mask lacks the ending single quotation mark. Cheers, Rob -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs