Re: Prepared Statement Name Truncation

On Sun, Nov 18, 2012 at 2:33 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Phil Sorber <phil(at)omniti(dot)com> writes:
>> An install of ours was having an issue with log files filling up the
>> disk rather quickly. After looking into it, the log was filling up
>> with NOTICE's caused by an ORM that was using a very long identifier
>> as a name for a prepared statement. It was a concatenation of tables
>> in the query.
>
> Just to be clear here ... does this ORM expect that it can concatenate
> *any* two legal identifiers into another one? If so, it's going to be
> broken no matter what the specific length limit is.
>
> regards, tom lane

I'm not sure if this particular ORM would expect that, but for the
sake of this discussion I think we should assume that whatever ORM
might be interfacing with postgres is doing "the right thing" as it
relates to the spec and we should work to minimize bad interactions. I
assume that was the point of the truncation to begin with, but
unintended consequences and all...

I understand your concern about the cost/benefit of fixing the length
to match spec.

I think making this a warning now would be a bit more forceful way to
let people know that this is a bad idea and this is a case where maybe
they need to work around postgres' lack of conformance to the spec. It
would most likely be caught sooner as well by DBA's. Then in 9.3 we
can make it an error with a GUC to easily override it back to a
warning. So that if it does break people's applications, they can
catch it in testing before an upgrade (assuming they test) and there
is a simple work around so they don't have to change their application
before upgrade. Also with the benefit of being even more forceful in
saying "Don't do that like that!" With a mention in the release notes
of course.