RE: libpq debug log - Mailing list pgsql-hackers

From tsunakawa.takay@fujitsu.com
Subject RE: libpq debug log
Date
Msg-id TYAPR01MB299075EBBF27F9FCB6E7D1EAFEDF0@TYAPR01MB2990.jpnprd01.prod.outlook.com
Whole thread Raw
In response to RE: libpq debug log  ("k.jamison@fujitsu.com" <k.jamison@fujitsu.com>)
List pgsql-hackers
From: k.jamison@fujitsu.com <k.jamison@fujitsu.com>
> I understand that protocol 2.0 is still supported, but it is only used for
> PostgreSQL versions 7.3 and earlier, which is not updated by fixes anymore
> since we only backpatch up to previous 5 versions. However I am not sure if
> it's a good idea, but how about if we just support this feature for protocol 3.

+1
I thought psqlODBC (still) allows the user to choose the protocol version, it looks like the current psqlODBC disallows
pre-3protocol: 

[libpq_connect()]
    MYLOG(0, "libpq connection to the database established.\n");
    pversion = PQprotocolVersion(pqconn);
    if (pversion < 3)
    {
        MYLOG(0, "Protocol version %d is not supported\n", pversion);
        goto cleanup;
    }


> There are similar chunks of code in fe-exec.c, PQsendPrepare(),
> PQsendDescribe(),
> etc. that already do something similar, so I just thought in hindsight if we can
> do the same.
>     if (PG_PROTOCOL_MAJOR(conn->pversion) >= 3)
>     {
>         <new code here>
>     }
>     else
>     {
>         /* Protocol 2.0 isn't supported */
>          printfPQExpBuffer(&conn->errorMessage,
>                            libpq_gettext("function requires at least protocol
> version 3.0\n"));
>          return 0;
>     }


I haven't looked at the patch and don't know the code structure, but I want the code clutter to be minimized.  So, I
thinkwe should avoid putting if statements like above here and there. 

Plus, I don't think it's not necessary to fail the processing when the protocol version is 2; we can just stop the
traceoutput.  So, how about disabling the trace output silently if the protocol turns out to be < 3 upon connection? 


Regards
Takayuki Tsunakawa






pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Add statistics to pg_stat_wal view for wal related parameter tuning
Next
From: Tomas Vondra
Date:
Subject: Re: Fix generate_useful_gather_paths for parallel unsafe pathkeys