On Sun, Nov 18, 2012 at 2:33 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Phil Sorber <p...@omniti.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. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
