From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@postgresql.org
Subject: Re: Incautious handling of overlength identifiers
In-reply-to: <17691.1482523168@sss.pgh.pa.us>
References: <17691.1482523168@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Fri, 23 Dec 2016 14:59:28 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <20640.1482525852.1@sss.pgh.pa.us>
Date: Fri, 23 Dec 2016 15:44:12 -0500
Message-ID: <20641.1482525852@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

I wrote:
> So what to do?  We could run around and fix these individual cases
> and call it good, but if we do, I will bet a very fine dinner that
> more such errors will sneak in before long.  Seems like we need a
> coding convention that discourages just randomly treating a C string
> as a valid value of type NAME.  Not sure how to get there though.

An alternative worth considering, especially for the back branches,
is simply to remove the Assert in hashname().  That would give us
the behavior that non-developers see anyway, which is that these
functions always fail to match overlength names, whether or not
the names would have matched after truncation.  Trying to apply
truncation more consistently could be left as an improvement
project for later.

			regards, tom lane


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