Re: syntax pb

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Marc Millas <marc(dot)millas(at)mokadb(dot)com>
Cc: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: syntax pb
Date: 2023-05-30 17:11:47
Message-ID: CAKFQuwZf_jnHZaoA5w7y92MsBVfS8-jpLhfMCGB4_A7+uO7gcQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, May 30, 2023 at 8:53 AM Marc Millas <marc(dot)millas(at)mokadb(dot)com> wrote

> This comes from a prod environment and even casting NULLs (which is more
> than strange, BTW) generates absurd errors.
>

If you want an input to be anything other than plain text (numbers
partially exempted) you need to cast it. Sure, some limited cases allow
for other parts of a query to infer untyped literals, but literals defined
at the top-level of a SELECT is not one of those places.

Too my understanding it looks like the parser did not parse the select
> distinct as we think he does.
>

The DISTINCT clause doesn't really come into play here at all, so if you
think it does you indeed have a misunderstanding.
Inputting literal NULLs, and using DISTINCT, are both, IMO, considered code
smells and seldom used. You still need to be able to interpret error
messages but if you are running actual queries with these things you may
have larger model design and query writing concerns to deal with in
addition to being able to identify the problems specific error messages are
pointing out and trying to fix them.

David J.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2023-05-30 17:31:21 Re: syntax pb
Previous Message Carsten Klein 2023-05-30 17:04:20 File-Access functions by default not executable by predefined role "pg_read_server_files"