On Fri, Mar 23, 2012 at 11:12 AM, Robert Haas wrote:
> On Thu, Mar 22, 2012 at 9:21 PM, Fujii Masao wrote:
>> On Fri, Mar 23, 2012 at 4:41 AM, Robert Haas wrote:
>>> Update docs on numeric storage requirements.
>>>
>>> Since 9.1, the minimum overhead is three bytes, not five.
>>
>> Thanks for th
On Thu, Mar 22, 2012 at 9:21 PM, Fujii Masao wrote:
> On Fri, Mar 23, 2012 at 4:41 AM, Robert Haas wrote:
>> Update docs on numeric storage requirements.
>>
>> Since 9.1, the minimum overhead is three bytes, not five.
>
> Thanks for the commit!
>
> I think that it's worth backporting this to 9.1.
On Tue, Oct 18, 2011 at 8:27 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Oct 15, 2011 at 11:24 AM, Tom Lane wrote:
>>> Uh, is that actually a true statement? I thought the result *did*
>>> include default values. That's more or less the point of returning them
>>> all, after all.
>
>>
On Fri, Mar 23, 2012 at 4:41 AM, Robert Haas wrote:
> Update docs on numeric storage requirements.
>
> Since 9.1, the minimum overhead is three bytes, not five.
Thanks for the commit!
I think that it's worth backporting this to 9.1. Thought?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPH
On Mon, Feb 13, 2012 at 1:57 PM, Jay Levitt wrote:
> Tom Lane wrote:
>>
>> Jay Levitt writes:
>>>
>>> I'm new to the codebase, but I think this patch reflects real-world
>>> usage;
>>> the PostgreSQL code itself always calls the length field "vl_len_", and I
>>> believe int32 is preferred over in
On Wed, Mar 21, 2012 at 10:35 PM, Fujii Masao wrote:
>> Numeric values are physically stored without any extra leading or
>> trailing zeroes. Thus, the declared precision and scale of a column
>> are maximums, not fixed allocations. (In this sense the numeric type
>> is more akin to varchar(n) tha
