Re: Remove inconsistent quotes from date_part error - Mailing list pgsql-hackers

From Nikhil Benesch
Subject Re: Remove inconsistent quotes from date_part error
Date
Msg-id CAPWqQZSPR5F7mwHM_BDsj3DLnPEx_id2e3YeFJLqQx=H2w-Nhg@mail.gmail.com
Whole thread Raw
In response to Re: Remove inconsistent quotes from date_part error  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Remove inconsistent quotes from date_part error
List pgsql-hackers
On Mon, Jan 3, 2022 at 1:14 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Hmm, I think you went a bit too far here.  The existing code intends
> to draw a distinction between "not recognized" (i.e., "we don't know
> what that word was you used") and "not supported" (i.e., "we know
> that word, but it doesn't seem to make sense in context, or we
> haven't got round to the case yet").  You've mashed those into the
> same error text, which I don't think we should do, especially
> since we're using distinct ERRCODE values for them.

Oops. I noticed that "inconsistency" between
ERRCODE_FEATURE_NOT_SUPPORTED and ERRCODE_INVALID_PARAMETER_VALUE and
then promptly blazed past it. Thanks for catching that.

> Attached v3 restores that distinction, and makes some other small
> tweaks.  (I found that there were actually a couple of spots in
> date.c that got it backwards, so admittedly this is a fine point
> that not everybody is on board with.  But let's make it consistent
> now.)

LGTM too, for whatever that's worth.



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: PostgreSQL stops when adding a breakpoint in CLion
Next
From: Ashwin Agrawal
Date:
Subject: Re: Throttling WAL inserts when the standby falls behind more than the configured replica_lag_in_bytes