Horton

Thread

Commits

  1. Refactor one conversion of SQLSTATE to string in elog.c

  1. unpack_sql_state not called?

    Peter Smith <smithpb2250@gmail.com> — 2021-08-30T23:32:41Z

    Hi. I noticed some code that seems the same as the nearby function
unpack_sql_state, and I wondered why it is not just calling it?

For example,


diff --git a/src/backend/utils/error/elog.c b/src/backend/utils/error/elog.c
index a3e1c59..d91ed98 100644
--- a/src/backend/utils/error/elog.c
+++ b/src/backend/utils/error/elog.c
@@ -3313,7 +3313,7 @@ send_message_to_frontend(ErrorData *edata)
                const char *sev;
                char            tbuf[12];
                int                     ssval;
-               int                     i;
+               char       *ssbuf;

                /* 'N' (Notice) is for nonfatal conditions, 'E' is for errors */
                pq_beginmessage(&msgbuf, (edata->elevel < ERROR) ? 'N' : 'E');
@@ -3326,15 +3326,10 @@ send_message_to_frontend(ErrorData *edata)

                /* unpack MAKE_SQLSTATE code */
                ssval = edata->sqlerrcode;
-               for (i = 0; i < 5; i++)
-               {
-                       tbuf[i] = PGUNSIXBIT(ssval);
-                       ssval >>= 6;
-               }
-               tbuf[i] = '\0';
+               ssbuf = unpack_sql_state(ssval);

                pq_sendbyte(&msgbuf, PG_DIAG_SQLSTATE);
-               err_sendstring(&msgbuf, tbuf);
+               err_sendstring(&msgbuf, ssbuf);

                /* M field is required per protocol, so always send something */
                pq_sendbyte(&msgbuf, PG_DIAG_MESSAGE_PRIMARY);

------
Kind Regards,
Peter Smith.
Fujitsu Australia

  2. Re: unpack_sql_state not called?

    Michael Paquier <michael@paquier.xyz> — 2021-08-31T01:31:18Z

    On Tue, Aug 31, 2021 at 09:32:41AM +1000, Peter Smith wrote:
> Hi. I noticed some code that seems the same as the nearby function
> unpack_sql_state, and I wondered why it is not just calling it?

This looks like a piece that could have been done in d46bc44, and
would not matter performance-wise.  No objections from here to do
this simplification.
--
Michael

  3. Re: unpack_sql_state not called?

    Peter Smith <smithpb2250@gmail.com> — 2021-08-31T04:01:02Z

    On Tue, Aug 31, 2021 at 11:31 AM Michael Paquier <michael@paquier.xyz> wrote:
>
> On Tue, Aug 31, 2021 at 09:32:41AM +1000, Peter Smith wrote:
> > Hi. I noticed some code that seems the same as the nearby function
> > unpack_sql_state, and I wondered why it is not just calling it?
>
> This looks like a piece that could have been done in d46bc44, and
> would not matter performance-wise.  No objections from here to do
> this simplification.

Thanks. Do you want me to re-post it as a patch attachment?

------
Kind Regards,
Peter Smith.
Fujitsu Australia

  4. Re: unpack_sql_state not called?

    Michael Paquier <michael@paquier.xyz> — 2021-08-31T04:06:56Z

    On Tue, Aug 31, 2021 at 02:01:02PM +1000, Peter Smith wrote:
> Do you want me to re-post it as a patch attachment?

No need.  Thanks.
--
Michael

  5. Re: unpack_sql_state not called?

    Peter Smith <smithpb2250@gmail.com> — 2021-09-01T22:49:11Z

    Thanks for pushing!

------
Kind Regards,
Peter Smith.
Fujitsu Australia