Re: Prepared Statement Name Truncation

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: Prepared Statement Name Truncation
Дата
Msg-id 50AADBAA.2030104@2ndQuadrant.com
обсуждение исходный текст
Ответ на Re: Prepared Statement Name Truncation  (Stephen Frost <sfrost@snowman.net>)
Список 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 по дате отправления:

Предыдущее
От: Yunong Xiao
Дата:
Сообщение: postgresql 9.2.1 dumps core on SmartOS(solaris) when the OS is rebooted
Следующее
От: Hari Babu
Дата:
Сообщение: Re: BUG #7643: Issuing a shutdown request while server startup leads to server hang