You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by F21 <f2...@gmail.com> on 2016/05/05 09:29:55 UTC
Avatica error codes
I recently found more time to work on the golang driver for
avatica/phoenix query server.
One of the things I want to do is to be able to trap transactional
conflicts. Here's one of them:
exceptions:"java.lang.RuntimeException: java.sql.SQLException: ERROR 523
(42900): Transaction aborted due to conflict with other mutations.
Conflict detected for transaction 1462439936409000000.\n\tat..."
error_code:4294967295 sql_state:"00000"
metadata:<server_address:"f826338-phoenix-server.f826338:8765" >
I noticed that the sql_state is usually 00000 as per
https://github.com/apache/calcite/blob/5e1cc5464413904466c357766843cd491b23f646/avatica/core/src/main/java/org/apache/calcite/avatica/remote/Service.java#L2236
However, I am not sure what 4294967295 means as I cannot find it if I
grep the calcite or phoenix code base. Interestingly, 4294967295 is the
maximum value of an unsigned_int. If I cause other errors such as
PhoenixParserException, the error code is also set to 4294967295.
Is there any reason why the sql_state and error_code from phoenix
(42900 and 523) is not being used in the error response?
Re: Avatica error codes
Posted by F21 <f2...@gmail.com>.
On 13/05/2016 5:30 PM, Julian Hyde wrote:
> Avatica\u2019s ErrorResponse currently has the same information as JDBC (String sqlState, int errorCode, String errorMessage). I don\u2019t think it\u2019s wise to add an errorName field, because it would be difficult to propagate it with a JDBC SQLException.
>
> If the error being thrown has a sqlState, then the sqlState code is sufficient. You can look up the name, e.g.
>
> SqlState.BY_CODE.get(\u201c01004\u201d).name()
>
> evaluates to \u201cWARNING_STRING_DATA_RIGHT_TRUNCATION\u201d.
>
> If the error being thrown is not a standard sqlState, I don\u2019t think there is a problem putting the error name in the sqlState field. SQLException doesn\u2019t check whether the code is valid, or even that it is 5 chars long.
>
> Julian
Ah that makes sense with the ErrorResponse being tied to SQLException.
Unfortunately, as a client of the avatica server, I am unable to call
`SqlState.BY_CODE.get(\u201c01004\u201d).name()` and will still need to maintain
my own map of error codes to the exception name.
Maybe it's possible to get an AST representation of
https://github.com/apache/phoenix/blob/a0504fba12363eaa27ea3fd224671e92cb11a468/phoenix-core/src/main/java/org/apache/phoenix/exception/SQLExceptionCode.java
to manipulate it into a language agnostic format, but I think that's
over engineering things for now.
The best solution is probably to maintain my own map and get a diff of
SQLExceptionCode.java on every release and add/remove error codes.
Re: Avatica error codes
Posted by Julian Hyde <jh...@apache.org>.
> On May 12, 2016, at 10:49 PM, F21 <f2...@gmail.com> wrote:
>
> @Julian: Your commits for CALCITE-1230 looks great! I assume those codes are going to be exceptions returned by avatica when it's processing the request before handing off to phoenix or some other processor. Is that correct?
It’s mainly reference data. If someone is implementing an Avatica server, when they throw an error, they are strongly encouraged to populate its sqlState value if it corresponds to a standard error. This table will make it easier for those implementers.
But Avatica will just pass through whatever sqlState value it gets.
>
> I am also wrapping up the golang driver. It should be ready for release soon. One of the things that might be useful is to have an machine readable "error_name" in the error response. For example, a phoenix error_name might be "transaction_conflict_exception" or "select_column_num_in_unionall_diffs". Reason for this is that "error_message" provides a user readable message, however, if we want to be able to say, retry if it's a transaction conflict, we would need to check that error_code is 523. Comparing against a bunch of error codes like 523 isn't as nice as doing error.ErrorName == "transaction_conflict_exception".
>
> I currently have a map mapping all of phoenix's error codes to a machine readable name like "transaction_conflict_exception" to achieve this in my driver, but this might be very difficult to maintain.
>
> This is probably something that phoenix needs to expose if this were to be implemented.
>
> Let me know what you guys think.
Avatica’s ErrorResponse currently has the same information as JDBC (String sqlState, int errorCode, String errorMessage). I don’t think it’s wise to add an errorName field, because it would be difficult to propagate it with a JDBC SQLException.
If the error being thrown has a sqlState, then the sqlState code is sufficient. You can look up the name, e.g.
SqlState.BY_CODE.get(“01004”).name()
evaluates to “WARNING_STRING_DATA_RIGHT_TRUNCATION”.
If the error being thrown is not a standard sqlState, I don’t think there is a problem putting the error name in the sqlState field. SQLException doesn’t check whether the code is valid, or even that it is 5 chars long.
Julian
Re: Avatica error codes
Posted by F21 <f2...@gmail.com>.
@Julian: Your commits for CALCITE-1230 looks great! I assume those codes
are going to be exceptions returned by avatica when it's processing the
request before handing off to phoenix or some other processor. Is that
correct?
I am also wrapping up the golang driver. It should be ready for release
soon. One of the things that might be useful is to have an machine
readable "error_name" in the error response. For example, a phoenix
error_name might be "transaction_conflict_exception" or
"select_column_num_in_unionall_diffs". Reason for this is that
"error_message" provides a user readable message, however, if we want to
be able to say, retry if it's a transaction conflict, we would need to
check that error_code is 523. Comparing against a bunch of error codes
like 523 isn't as nice as doing error.ErrorName ==
"transaction_conflict_exception".
I currently have a map mapping all of phoenix's error codes to a machine
readable name like "transaction_conflict_exception" to achieve this in
my driver, but this might be very difficult to maintain.
This is probably something that phoenix needs to expose if this were to
be implemented.
Let me know what you guys think.
On 7/05/2016 11:37 AM, Julian Hyde wrote:
> I agree. https://issues.apache.org/jira/browse/CALCITE-1049 <https://issues.apache.org/jira/browse/CALCITE-1049> is about this. Phoenix helpfully returns both a sqlState and a (I presume Phoenix-specific) error code, and Avatica has slots {errorMessage, errorCode, sqlState, severity}, somehow the sqlState doesn\u2019t get populated.
>
>> On May 6, 2016, at 10:55 AM, James Taylor <ja...@apache.org> wrote:
>>
>> From a clients perspective, it'd be nice in Avatica if you kept the
>> sqlstate and error code that's thrown on the server side. I'm sure all the
>> different adapters vary widely in terms of the codes they use and clients
>> may depend on these (especially the particular error code).
>>
>> Thanks,
>> James
>>
>> On Fri, May 6, 2016 at 10:46 AM, Julian Hyde <jh...@apache.org> wrote:
>>
>>> You inspired me to add SQLSTATE reference data to Avatica, as a new enum
>>> SqlState[1]. Reviewing SqlState.java[2] I can say for sure that 42900 and
>>> 523 are not standard codes.
>>>
>>> Please review SqlState.java before it goes into Avatica. Is there anything
>>> we can add to make it more useful to client applications?
>>>
>>> Yes, what you are seeing duplicates 1049 and 1187. Would anyone like to
>>> work on these?
>>>
>>> Julian
>>>
>>> [1] https://issues.apache.org/jira/browse/CALCITE-1230
>>>
>>> [2]
>>> https://raw.githubusercontent.com/julianhyde/calcite/1230-sql-state/avatica/core/src/main/java/org/apache/calcite/avatica/SqlState.java
>>>
>>>> On May 5, 2016, at 4:59 PM, F21 <f2...@gmail.com> wrote:
>>>>
>>>> Hey Julian,
>>>>
>>>> I was not able to find 42900 in the SQLSTATE here[1], so it might be a
>>> Phoenix specific one.
>>>> 523 appears to be an error code specific to phoenix. I also found
>>> CALCITE-1049 and CALCITE-1187 which appears to report the same problem, so
>>> hopefully this is something that will be improved in the future.
>>>> Anyway, this is something I can work around by examining the error
>>> message for now.
>>>> Cheers,
>>>> Francis
>>>>
>>>> [1] https://en.wikibooks.org/wiki/Structured_Query_Language/SQLSTATE
>>>>
>>>> On 6/05/2016 5:40 AM, Julian Hyde wrote:
>>>>> It makes sense that Avatica should propagate error codes. Especially
>>>>> if they adhere to the SQL_STATE standard.
>>>>>
>>>>> By the way Calcite doesn't do a good job of this. It has
>>>>>
>>> https://calcite.apache.org/apidocs/org/apache/calcite/sql/SqlStateCodes.html
>>>>> but there are only 3 codes defined.
>>>>>
>>>>> It looks as if Phoenix does a lot better.
>>>>>
>>>>> Julian
>>>>>
>>>>>
>>>>> On Thu, May 5, 2016 at 2:29 AM, F21 <f2...@gmail.com> wrote:
>>>>>> I recently found more time to work on the golang driver for
>>> avatica/phoenix
>>>>>> query server.
>>>>>>
>>>>>> One of the things I want to do is to be able to trap transactional
>>>>>> conflicts. Here's one of them:
>>>>>>
>>>>>> exceptions:"java.lang.RuntimeException: java.sql.SQLException: ERROR
>>> 523
>>>>>> (42900): Transaction aborted due to conflict with other mutations.
>>> Conflict
>>>>>> detected for transaction 1462439936409000000.\n\tat..."
>>>>>> error_code:4294967295 sql_state:"00000"
>>>>>> metadata:<server_address:"f826338-phoenix-server.f826338:8765" >
>>>>>>
>>>>>> I noticed that the sql_state is usually 00000 as per
>>>>>>
>>> https://github.com/apache/calcite/blob/5e1cc5464413904466c357766843cd491b23f646/avatica/core/src/main/java/org/apache/calcite/avatica/remote/Service.java#L2236
>>>>>> However, I am not sure what 4294967295 means as I cannot find it if I
>>> grep
>>>>>> the calcite or phoenix code base. Interestingly, 4294967295 is the
>>> maximum
>>>>>> value of an unsigned_int. If I cause other errors such as
>>>>>> PhoenixParserException, the error code is also set to 4294967295.
>>>>>>
>>>>>> Is there any reason why the sql_state and error_code from phoenix
>>> (42900
>>>>>> and 523) is not being used in the error response?
>>>>>>
>>>>>>
>>>
>
Re: Avatica error codes
Posted by Julian Hyde <jh...@apache.org>.
I agree. https://issues.apache.org/jira/browse/CALCITE-1049 <https://issues.apache.org/jira/browse/CALCITE-1049> is about this. Phoenix helpfully returns both a sqlState and a (I presume Phoenix-specific) error code, and Avatica has slots {errorMessage, errorCode, sqlState, severity}, somehow the sqlState doesn’t get populated.
> On May 6, 2016, at 10:55 AM, James Taylor <ja...@apache.org> wrote:
>
> From a clients perspective, it'd be nice in Avatica if you kept the
> sqlstate and error code that's thrown on the server side. I'm sure all the
> different adapters vary widely in terms of the codes they use and clients
> may depend on these (especially the particular error code).
>
> Thanks,
> James
>
> On Fri, May 6, 2016 at 10:46 AM, Julian Hyde <jh...@apache.org> wrote:
>
>> You inspired me to add SQLSTATE reference data to Avatica, as a new enum
>> SqlState[1]. Reviewing SqlState.java[2] I can say for sure that 42900 and
>> 523 are not standard codes.
>>
>> Please review SqlState.java before it goes into Avatica. Is there anything
>> we can add to make it more useful to client applications?
>>
>> Yes, what you are seeing duplicates 1049 and 1187. Would anyone like to
>> work on these?
>>
>> Julian
>>
>> [1] https://issues.apache.org/jira/browse/CALCITE-1230
>>
>> [2]
>> https://raw.githubusercontent.com/julianhyde/calcite/1230-sql-state/avatica/core/src/main/java/org/apache/calcite/avatica/SqlState.java
>>
>>> On May 5, 2016, at 4:59 PM, F21 <f2...@gmail.com> wrote:
>>>
>>> Hey Julian,
>>>
>>> I was not able to find 42900 in the SQLSTATE here[1], so it might be a
>> Phoenix specific one.
>>>
>>> 523 appears to be an error code specific to phoenix. I also found
>> CALCITE-1049 and CALCITE-1187 which appears to report the same problem, so
>> hopefully this is something that will be improved in the future.
>>>
>>> Anyway, this is something I can work around by examining the error
>> message for now.
>>>
>>> Cheers,
>>> Francis
>>>
>>> [1] https://en.wikibooks.org/wiki/Structured_Query_Language/SQLSTATE
>>>
>>> On 6/05/2016 5:40 AM, Julian Hyde wrote:
>>>> It makes sense that Avatica should propagate error codes. Especially
>>>> if they adhere to the SQL_STATE standard.
>>>>
>>>> By the way Calcite doesn't do a good job of this. It has
>>>>
>> https://calcite.apache.org/apidocs/org/apache/calcite/sql/SqlStateCodes.html
>>>> but there are only 3 codes defined.
>>>>
>>>> It looks as if Phoenix does a lot better.
>>>>
>>>> Julian
>>>>
>>>>
>>>> On Thu, May 5, 2016 at 2:29 AM, F21 <f2...@gmail.com> wrote:
>>>>> I recently found more time to work on the golang driver for
>> avatica/phoenix
>>>>> query server.
>>>>>
>>>>> One of the things I want to do is to be able to trap transactional
>>>>> conflicts. Here's one of them:
>>>>>
>>>>> exceptions:"java.lang.RuntimeException: java.sql.SQLException: ERROR
>> 523
>>>>> (42900): Transaction aborted due to conflict with other mutations.
>> Conflict
>>>>> detected for transaction 1462439936409000000.\n\tat..."
>>>>> error_code:4294967295 sql_state:"00000"
>>>>> metadata:<server_address:"f826338-phoenix-server.f826338:8765" >
>>>>>
>>>>> I noticed that the sql_state is usually 00000 as per
>>>>>
>> https://github.com/apache/calcite/blob/5e1cc5464413904466c357766843cd491b23f646/avatica/core/src/main/java/org/apache/calcite/avatica/remote/Service.java#L2236
>>>>>
>>>>> However, I am not sure what 4294967295 means as I cannot find it if I
>> grep
>>>>> the calcite or phoenix code base. Interestingly, 4294967295 is the
>> maximum
>>>>> value of an unsigned_int. If I cause other errors such as
>>>>> PhoenixParserException, the error code is also set to 4294967295.
>>>>>
>>>>> Is there any reason why the sql_state and error_code from phoenix
>> (42900
>>>>> and 523) is not being used in the error response?
>>>>>
>>>>>
>>>
>>
>>
Re: Avatica error codes
Posted by James Taylor <ja...@apache.org>.
From a clients perspective, it'd be nice in Avatica if you kept the
sqlstate and error code that's thrown on the server side. I'm sure all the
different adapters vary widely in terms of the codes they use and clients
may depend on these (especially the particular error code).
Thanks,
James
On Fri, May 6, 2016 at 10:46 AM, Julian Hyde <jh...@apache.org> wrote:
> You inspired me to add SQLSTATE reference data to Avatica, as a new enum
> SqlState[1]. Reviewing SqlState.java[2] I can say for sure that 42900 and
> 523 are not standard codes.
>
> Please review SqlState.java before it goes into Avatica. Is there anything
> we can add to make it more useful to client applications?
>
> Yes, what you are seeing duplicates 1049 and 1187. Would anyone like to
> work on these?
>
> Julian
>
> [1] https://issues.apache.org/jira/browse/CALCITE-1230
>
> [2]
> https://raw.githubusercontent.com/julianhyde/calcite/1230-sql-state/avatica/core/src/main/java/org/apache/calcite/avatica/SqlState.java
>
> > On May 5, 2016, at 4:59 PM, F21 <f2...@gmail.com> wrote:
> >
> > Hey Julian,
> >
> > I was not able to find 42900 in the SQLSTATE here[1], so it might be a
> Phoenix specific one.
> >
> > 523 appears to be an error code specific to phoenix. I also found
> CALCITE-1049 and CALCITE-1187 which appears to report the same problem, so
> hopefully this is something that will be improved in the future.
> >
> > Anyway, this is something I can work around by examining the error
> message for now.
> >
> > Cheers,
> > Francis
> >
> > [1] https://en.wikibooks.org/wiki/Structured_Query_Language/SQLSTATE
> >
> > On 6/05/2016 5:40 AM, Julian Hyde wrote:
> >> It makes sense that Avatica should propagate error codes. Especially
> >> if they adhere to the SQL_STATE standard.
> >>
> >> By the way Calcite doesn't do a good job of this. It has
> >>
> https://calcite.apache.org/apidocs/org/apache/calcite/sql/SqlStateCodes.html
> >> but there are only 3 codes defined.
> >>
> >> It looks as if Phoenix does a lot better.
> >>
> >> Julian
> >>
> >>
> >> On Thu, May 5, 2016 at 2:29 AM, F21 <f2...@gmail.com> wrote:
> >>> I recently found more time to work on the golang driver for
> avatica/phoenix
> >>> query server.
> >>>
> >>> One of the things I want to do is to be able to trap transactional
> >>> conflicts. Here's one of them:
> >>>
> >>> exceptions:"java.lang.RuntimeException: java.sql.SQLException: ERROR
> 523
> >>> (42900): Transaction aborted due to conflict with other mutations.
> Conflict
> >>> detected for transaction 1462439936409000000.\n\tat..."
> >>> error_code:4294967295 sql_state:"00000"
> >>> metadata:<server_address:"f826338-phoenix-server.f826338:8765" >
> >>>
> >>> I noticed that the sql_state is usually 00000 as per
> >>>
> https://github.com/apache/calcite/blob/5e1cc5464413904466c357766843cd491b23f646/avatica/core/src/main/java/org/apache/calcite/avatica/remote/Service.java#L2236
> >>>
> >>> However, I am not sure what 4294967295 means as I cannot find it if I
> grep
> >>> the calcite or phoenix code base. Interestingly, 4294967295 is the
> maximum
> >>> value of an unsigned_int. If I cause other errors such as
> >>> PhoenixParserException, the error code is also set to 4294967295.
> >>>
> >>> Is there any reason why the sql_state and error_code from phoenix
> (42900
> >>> and 523) is not being used in the error response?
> >>>
> >>>
> >
>
>
Re: Avatica error codes
Posted by Julian Hyde <jh...@apache.org>.
You inspired me to add SQLSTATE reference data to Avatica, as a new enum SqlState[1]. Reviewing SqlState.java[2] I can say for sure that 42900 and 523 are not standard codes.
Please review SqlState.java before it goes into Avatica. Is there anything we can add to make it more useful to client applications?
Yes, what you are seeing duplicates 1049 and 1187. Would anyone like to work on these?
Julian
[1] https://issues.apache.org/jira/browse/CALCITE-1230
[2] https://raw.githubusercontent.com/julianhyde/calcite/1230-sql-state/avatica/core/src/main/java/org/apache/calcite/avatica/SqlState.java
> On May 5, 2016, at 4:59 PM, F21 <f2...@gmail.com> wrote:
>
> Hey Julian,
>
> I was not able to find 42900 in the SQLSTATE here[1], so it might be a Phoenix specific one.
>
> 523 appears to be an error code specific to phoenix. I also found CALCITE-1049 and CALCITE-1187 which appears to report the same problem, so hopefully this is something that will be improved in the future.
>
> Anyway, this is something I can work around by examining the error message for now.
>
> Cheers,
> Francis
>
> [1] https://en.wikibooks.org/wiki/Structured_Query_Language/SQLSTATE
>
> On 6/05/2016 5:40 AM, Julian Hyde wrote:
>> It makes sense that Avatica should propagate error codes. Especially
>> if they adhere to the SQL_STATE standard.
>>
>> By the way Calcite doesn't do a good job of this. It has
>> https://calcite.apache.org/apidocs/org/apache/calcite/sql/SqlStateCodes.html
>> but there are only 3 codes defined.
>>
>> It looks as if Phoenix does a lot better.
>>
>> Julian
>>
>>
>> On Thu, May 5, 2016 at 2:29 AM, F21 <f2...@gmail.com> wrote:
>>> I recently found more time to work on the golang driver for avatica/phoenix
>>> query server.
>>>
>>> One of the things I want to do is to be able to trap transactional
>>> conflicts. Here's one of them:
>>>
>>> exceptions:"java.lang.RuntimeException: java.sql.SQLException: ERROR 523
>>> (42900): Transaction aborted due to conflict with other mutations. Conflict
>>> detected for transaction 1462439936409000000.\n\tat..."
>>> error_code:4294967295 sql_state:"00000"
>>> metadata:<server_address:"f826338-phoenix-server.f826338:8765" >
>>>
>>> I noticed that the sql_state is usually 00000 as per
>>> https://github.com/apache/calcite/blob/5e1cc5464413904466c357766843cd491b23f646/avatica/core/src/main/java/org/apache/calcite/avatica/remote/Service.java#L2236
>>>
>>> However, I am not sure what 4294967295 means as I cannot find it if I grep
>>> the calcite or phoenix code base. Interestingly, 4294967295 is the maximum
>>> value of an unsigned_int. If I cause other errors such as
>>> PhoenixParserException, the error code is also set to 4294967295.
>>>
>>> Is there any reason why the sql_state and error_code from phoenix (42900
>>> and 523) is not being used in the error response?
>>>
>>>
>
Re: Avatica error codes
Posted by F21 <f2...@gmail.com>.
Hey Julian,
I was not able to find 42900 in the SQLSTATE here[1], so it might be a
Phoenix specific one.
523 appears to be an error code specific to phoenix. I also found
CALCITE-1049 and CALCITE-1187 which appears to report the same problem,
so hopefully this is something that will be improved in the future.
Anyway, this is something I can work around by examining the error
message for now.
Cheers,
Francis
[1] https://en.wikibooks.org/wiki/Structured_Query_Language/SQLSTATE
On 6/05/2016 5:40 AM, Julian Hyde wrote:
> It makes sense that Avatica should propagate error codes. Especially
> if they adhere to the SQL_STATE standard.
>
> By the way Calcite doesn't do a good job of this. It has
> https://calcite.apache.org/apidocs/org/apache/calcite/sql/SqlStateCodes.html
> but there are only 3 codes defined.
>
> It looks as if Phoenix does a lot better.
>
> Julian
>
>
> On Thu, May 5, 2016 at 2:29 AM, F21 <f2...@gmail.com> wrote:
>> I recently found more time to work on the golang driver for avatica/phoenix
>> query server.
>>
>> One of the things I want to do is to be able to trap transactional
>> conflicts. Here's one of them:
>>
>> exceptions:"java.lang.RuntimeException: java.sql.SQLException: ERROR 523
>> (42900): Transaction aborted due to conflict with other mutations. Conflict
>> detected for transaction 1462439936409000000.\n\tat..."
>> error_code:4294967295 sql_state:"00000"
>> metadata:<server_address:"f826338-phoenix-server.f826338:8765" >
>>
>> I noticed that the sql_state is usually 00000 as per
>> https://github.com/apache/calcite/blob/5e1cc5464413904466c357766843cd491b23f646/avatica/core/src/main/java/org/apache/calcite/avatica/remote/Service.java#L2236
>>
>> However, I am not sure what 4294967295 means as I cannot find it if I grep
>> the calcite or phoenix code base. Interestingly, 4294967295 is the maximum
>> value of an unsigned_int. If I cause other errors such as
>> PhoenixParserException, the error code is also set to 4294967295.
>>
>> Is there any reason why the sql_state and error_code from phoenix (42900
>> and 523) is not being used in the error response?
>>
>>
Re: Avatica error codes
Posted by Julian Hyde <jh...@apache.org>.
It makes sense that Avatica should propagate error codes. Especially
if they adhere to the SQL_STATE standard.
By the way Calcite doesn't do a good job of this. It has
https://calcite.apache.org/apidocs/org/apache/calcite/sql/SqlStateCodes.html
but there are only 3 codes defined.
It looks as if Phoenix does a lot better.
Julian
On Thu, May 5, 2016 at 2:29 AM, F21 <f2...@gmail.com> wrote:
> I recently found more time to work on the golang driver for avatica/phoenix
> query server.
>
> One of the things I want to do is to be able to trap transactional
> conflicts. Here's one of them:
>
> exceptions:"java.lang.RuntimeException: java.sql.SQLException: ERROR 523
> (42900): Transaction aborted due to conflict with other mutations. Conflict
> detected for transaction 1462439936409000000.\n\tat..."
> error_code:4294967295 sql_state:"00000"
> metadata:<server_address:"f826338-phoenix-server.f826338:8765" >
>
> I noticed that the sql_state is usually 00000 as per
> https://github.com/apache/calcite/blob/5e1cc5464413904466c357766843cd491b23f646/avatica/core/src/main/java/org/apache/calcite/avatica/remote/Service.java#L2236
>
> However, I am not sure what 4294967295 means as I cannot find it if I grep
> the calcite or phoenix code base. Interestingly, 4294967295 is the maximum
> value of an unsigned_int. If I cause other errors such as
> PhoenixParserException, the error code is also set to 4294967295.
>
> Is there any reason why the sql_state and error_code from phoenix (42900
> and 523) is not being used in the error response?
>
>