Обсуждение: BUG #16726: Invalid input syntax is not a useful error message

The following bug has been logged on the website:

Bug reference:      16726
Logged by:          No useful error message
Email address:      nozdrum@gmx.de
PostgreSQL version: 13.0
Operating system:   Linux
Description:

I tried to update the uuid-value of a user with a uuid-literal. Since the
documentation on this is so useless:
https://www.postgresql.org/docs/13/datatype-uuid.html I had to try and
finally give up.

Example-query i tried:
update users set
  some_uuid_field = 'dec3d6c4-c32e-45c6-1eae3df44fbf'
where
  id = 5

I tried ( as is suggested in your documentation) to set with and without
sorounding single quotation mark and with and without braces. I always got
the same useless error message
`ERROR:  invalid input syntax for type uuid:
"dec3d6c4-c32e-45c6-1eae3df44fbf"`

I also tried curly braces ( as suggested by your awful documentation ), but
this just leads to 
`syntax error at or near "{"`

What I want:
a) That your documentation tells me the syntax for this
b) That your error messages FOR ONCE are not useless and tell me the
expected syntax, you are wasting millions of hours of developer time and
human life, because you can not be asked to make useful error messages.

On 11/19/20 12:55 AM, PG Bug reporting form wrote:
> The following bug has been logged on the website:
> 
> Example-query i tried:
> update users set
>   some_uuid_field = 'dec3d6c4-c32e-45c6-1eae3df44fbf'
> where
>   id = 5
> 
> What I want:
> a) That your documentation tells me the syntax for this
> b) That your error messages FOR ONCE are not useless and tell me the
> expected syntax, you are wasting millions of hours of developer time and
> human life, because you can not be asked to make useful error messages.

The documentation tells you exactly what the syntax should be, and the
error message couldn't be clearer.  It says "specifically a group of 8
digits followed by three groups of 4 digits followed by a group of 12
digits" but you've only supplied two groups of 4 digits in the middle.

-- 
Vik Fearing

> On Nov 18, 2020, at 15:55, PG Bug reporting form <noreply@postgresql.org> wrote:
>
> I tried to update the uuid-value of a user with a uuid-literal. Since the
> documentation on this is so useless:
> https://www.postgresql.org/docs/13/datatype-uuid.html I had to try and
> finally give up.

The documentation you link to gives the exact syntax, and even gives examples:

> In its canonical textual representation, the 16 octets of a UUID are represented as 32 hexadecimal (base-16) digits,
displayedin five groups separated by hyphens, in the form 8-4-4-4-12 for a total of 36 characters (32 hexadecimal
charactersand 4 hyphens). For example: 
>
> 123e4567-e89b-12d3-a456-426614174000
> xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

The error message is exactly correct: You did not give the correct format for the character representation of the UUID.
--
-- Christophe Pettus
   xof@thebuild.com

Hi,

I find your bug report inappropriately disrespectful - you realize this
is an open source project, and you're not paying us for development?
Not to say that I think your tone would be appropriate in a commercial
setting either.

On 2020-11-18 23:55:44 +0000, PG Bug reporting form wrote:
> I tried to update the uuid-value of a user with a uuid-literal. Since the
> documentation on this is so useless:
> https://www.postgresql.org/docs/13/datatype-uuid.html I had to try and
> finally give up.

The docs say:

"A UUID is written as a sequence of lower-case hexadecimal digits, in
several groups separated by hyphens, specifically a group of 8 digits
followed by three groups of 4 digits followed by a group of 12 digits,
for a total of 32 digits representing the 128 bits. An example of a UUID
in this standard form is:"

What exactly are you lacking in this description?

The docs also give you example UUIDs to try - which you evidently
didn't.


> Example-query i tried:
> update users set
>   some_uuid_field = 'dec3d6c4-c32e-45c6-1eae3df44fbf'
> where
>   id = 5

That's not a valid uuid, you're missing one group of four digits.


> b) That your error messages FOR ONCE are not useless and tell me the
> expected syntax, you are wasting millions of hours of developer time and
> human life, because you can not be asked to make useful error
> messages.

a) How about being nice to people
b) There's a limit to the amount of detail in error messages we can
   provide - e.g. for types / operators that are allowed to be used for
   row level security, we can't include anything that'd allow inferring
   content from the error message.
c) Please make a proposal.


- Andres

On 2020-Nov-18, PG Bug reporting form wrote:

> I also tried curly braces ( as suggested by your awful documentation ), but
> this just leads to 
> `syntax error at or near "{"`

Actually, curly braces work just fine:

=# create table users (some_uuid_field uuid);
CREATE TABLE

=# insert into users values ('{dec3d6c4-c32e-45c6-0000-1eae3df44fbf}');
INSERT 0 1

(I fixed the broken UUID value, obviously.)

The problem with that, I suspect, is that you *replaced* the
single-quote delimiters with braces, rather than *add* the braces inside
the quoted literal.  That's what gives the error message you suggest:

=# insert into users values ({dec3d6c4-c32e-45c6-0000-1eae3df44fbf});
ERROR:  syntax error at or near "{"
LÍNEA 1: insert into users values ({dec3d6c4-c32e-45c6-0000-1eae3df44...
                                   ^


> What I want:

> b) That your error messages FOR ONCE are not useless and tell me the
> expected syntax, you are wasting millions of hours of developer time and
> human life, because you can not be asked to make useful error messages.

I think you're suggesting something like this:

insert into users values ('{dec3d6c4-c32e-45c6-000-1eae3df44fbf}');
ERROR:  invalid input syntax for type uuid: "{dec3d6c4-c32e-45c6-000-1eae3df44fbf}"
LÍNEA 1: insert into users values ('{dec3d6c4-c32e-45c6-000-1eae3df44...
                                   ^
HINT: Valid UUID values are of the form 'FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF'.

This is not impossible, but I think it'd be overkill, and it fails to
convey that there are other possible formats (if we tried to list them
all, it'd be pretty cumbersome).  Would this be really all that
valuable?

However, before embarking on such an implementation, you would certainly
owe this group an apology for your rudeness and an admission that we do
spend a lot of time producing pretty decent error messages most of the
time.