Re: array_in sub function ReadArrayDimensions error message - Mailing list pgsql-hackers
From | jian he |
---|---|
Subject | Re: array_in sub function ReadArrayDimensions error message |
Date | |
Msg-id | CACJufxFS21wzDeHp4PBY6T9kRmCkUNkDznBqyFRpEOrkGbZReQ@mail.gmail.com Whole thread Raw |
In response to | Re: array_in sub function ReadArrayDimensions error message (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: array_in sub function ReadArrayDimensions error message
|
List | pgsql-hackers |
On Tue, Jul 9, 2024 at 11:31 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > jian he <jian.universality@gmail.com> writes: > > On Mon, Jul 8, 2024 at 10:42 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> One possibility could be > >> ... > >> that is, only say "Missing "]"" if there's no ']' anywhere, and > >> otherwise just say the dimensions are wrong. This could be fooled > >> by a ']' that's part of some string in the data, but even then the > >> errdetail isn't wrong. > >> > >> Or we could just say "Array dimensions have invalid syntax." > >> unconditionally. > > > please check attached. > > Meh. This just replaces one possibly-off-point error message > with a different one that will be off-point in a different set > of cases. I think we should simply reduce the specificity of > the message. After playing around, I agree with you that reducing the specificity of the message here is better. > BTW, I think we have pretty much the same issue with respect > to the check for "=" later on. For instance, if someone > is confused about whether to insert commas: > > =# select '[1:1],[1:2]={{3,4}}'::int[]; > ERROR: malformed array literal: "[1:1],[1:2]={{3,4}}" > LINE 1: select '[1:1],[1:2]={{3,4}}'::int[]; > ^ > DETAIL: Missing "=" after array dimensions. > > Here again, the problem is not a missing "=", it's invalid > syntax somewhere before that. > > Another thing we could consider doing here (and similarly > for your original case) is > > DETAIL: Expected "=" not "," after array dimensions. > > The advantage of this is that it provides a little more > clarity as to exactly where things went wrong. > this looks good to me. I also found other issues, like. select '[-2:2147483644]={3}'::int[]; ERROR: malformed array literal: "[-2:2147483644]={3}" LINE 1: select '[-2:2147483644]={3}'::int[]; ^ DETAIL: Specified array dimensions do not match array contents. select '[-2:2147483645]={3}'::int[]; ERROR: array size exceeds the maximum allowed (134217727) LINE 1: select '[-2:2147483645]={3}'::int[]; ^ Both cases exceed the maximum allowed (134217727), but error is different. also "ERROR: array size exceeds the maximum allowed (134217727)" is weird. we are still validating the dimension info function, we don't even know the actual size of the array. maybe "ERROR: array dimensions specified array size exceeds the maximum allowed (134217727)" This customized dimension info is kind of obscure, even the documentation of it is buried in the third paragraph of https://www.postgresql.org/docs/current/arrays.html#ARRAYS-IO to address David G. Johnston concern, in ReadArrayDimensions, some error message can unconditionally mention errhint like: errhint("array dimension template is \"[lower_bound:upper_bound]\", we can optional have 6 of this"
pgsql-hackers by date: