From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Heller <info@zilence.net>
cc: pgsql-interfaces@postgresql.org
Subject: Re: Protocol Question
In-reply-to: 
 <CAGTxmOvGwPoBC01-XnS-1cTNE29T2+QRuheQBPSrKNpbgVpmXQ@mail.gmail.com>
References: 
 <CAGTxmOvGwPoBC01-XnS-1cTNE29T2+QRuheQBPSrKNpbgVpmXQ@mail.gmail.com>
Comments: In-reply-to Thomas Heller <info@zilence.net>
 message dated "Mon, 11 Aug 2014 16:03:58 +0200"
Date: Mon, 11 Aug 2014 11:06:19 -0400
Message-ID: <22826.1407769579@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-interfaces-owner@postgresql.org

Thomas Heller <info@zilence.net> writes:
> The first 16 bits (well skip the first 40) in every DataRow ('D') packet
> refer to the number of columns following. Is there any way that this number
> is different from the number received in the RowDescription ('T')?

A quick look into libpq says that it doesn't support them being different:

    /* Get the field count and make sure it's what we expect */
    if (pqGetInt(&tupnfields, 2, conn))
    {
        /* We should not run out of data here, so complain */
        errmsg = libpq_gettext("insufficient data in \"D\" message");
        goto advance_and_error;
    }

    if (tupnfields != nfields)
    {
        errmsg = libpq_gettext("unexpected field count in \"D\" message");
        goto advance_and_error;
    }

> Currently I use an assert since I assume it always is the same, however I
> only have tested with a very limited dataset so far.

An assert seems overly optimistic.  libpq has an explicit test with an
error recovery path, you should too.

			regards, tom lane


-- 
Sent via pgsql-interfaces mailing list (pgsql-interfaces@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-interfaces