Hi Peter,
On Thu, Sep 3, 2026 at 4:05 AM Peter Eisentraut <[email protected]> wrote:
>
> On 01.09.26 08:28, Xuneng Zhou wrote:
> > 'NO_THROW' was added to make those statuses available for ordinary
> > application control flow. Without it, 'timeout' and 'not in recovery'
> > are raised as SQL errors. With it, they are returned as status values,
> > allowing the application to retry, report replication lag, refresh its
> > routing information, or direct a subsequent read to the primary. In
> > that sense, 'NO_THROW' selects how these expected wait outcomes are
> > reported: through the error channel or through the result row.
>
> This just explains the technical distinction, not why it's needed.
> Applications or client frameworks could just as well inspect an error
> return with for example an appropriate error code. That's what they'd d
> for any other command.
That's interesting. I was unaware of the use of error codes as the
states of application logical control flow. But that use seems not
elegant to me or maybe I misunderstood its usage.
ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE
ERRCODE_QUERY_CANCELED
These error codes are overloaded in terms of meaning and the
conditions lead to each. They are not tailed for the return states of
WAIT FOR. If I was a user, I would be less happy to figure out what
they mean and what they are represented for.
errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("recovery is not in progress"),
errcode + errmsg together seems to be a more sensible state, but it
would require extra parsing effort.
But this alone seems not warrant a standalone option. The direction
that Rithvika put earlier now makes more sense to me. But I would
suggest adjusting its expression and adding examples. I'll reply later
while I get more time.
--
Regards,
Xuneng Zhou
HighGo Software Co., Ltd.
