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.
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" |