Re: Binary support for pgoutput plugin - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Binary support for pgoutput plugin
Date
Msg-id 20200715024753.tn3bnjj4uxrqt6qy@alap3.anarazel.de
Whole thread Raw
In response to Re: Binary support for pgoutput plugin  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Binary support for pgoutput plugin  (Dave Cramer <davecramer@gmail.com>)
List pgsql-hackers
Hi,

On 2020-07-14 22:28:48 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > What is the gain in having these checks? recv functions need to be safe
> > against arbitrary input, so a type crosscheck doesn't buy additional
> > safety in that regard. Not that a potential attacker couldn't just
> > change the content anyways?
> 
> You're confusing security issues with user-friendliness issues.
> Detecting that you sent the wrong type via an OID mismatch error
> is a lot less painful than trying to figure out why you've got
> errors along the line of "incorrect binary data format".

An oid mismatch error without knowing what that's about isn't very
helpful either.

How about adding an errcontext that shows the "source type oid", the
target type oid & type name and, for records, the column name of the
target table? That'd make this a lot easier to debug.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Is it useful to record whether plans are generic or custom?
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: GSSENC'ed connection stalls while reconnection attempts.