Re: Prepared Statement Name Truncation - Mailing list pgsql-bugs

From Craig Ringer
Subject Re: Prepared Statement Name Truncation
Date
Msg-id 50AADBAA.2030104@2ndQuadrant.com
Whole thread Raw
In response to Re: Prepared Statement Name Truncation  (Stephen Frost <sfrost@snowman.net>)
List pgsql-bugs
On 11/19/2012 09:43 PM, Stephen Frost wrote:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> Let me be clear here: I don't think we can or should ever make this
>> into an error by default. Doing that would break spec-compliant
>> applications, whether or not they are using names that actually have
>> any conflicts.
>
> If we increase the length to the spec requirement (full disclosure- I
> havn't checked the spec on this myself), I'd be for making it an error
> if someone goes over that limit. Right now we have a risk of spec
> compliant applications not working under PG for nearly zero good
> justification in today's age (iow- I don't really buy the concern about
> the size, and if that is a reasonable concern then we could look at
> putting in the effort to make it variable length and seriously reduce
> today's wasted space).
Wasted space is only part of the issue; it's also potentially
significantly cheaper to compare and copy fixed length names, especially
when you can copy on-stack arrays rather than palloc'ing memory.

I have not checked to see whether this is a concern in Pg's codebase;
I'm just aware it's been a reason for the use of fixed length strings in
software in general.

--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

pgsql-bugs by date:

Previous
From: Yunong Xiao
Date:
Subject: postgresql 9.2.1 dumps core on SmartOS(solaris) when the OS is rebooted
Next
From: Hari Babu
Date:
Subject: Re: BUG #7643: Issuing a shutdown request while server startup leads to server hang