On Sun, Sep 15, 2013 at 8:05 PM, Jeff Janes wrote:
> But note that the current behavior is worse in this regard. If you specify
> a scale of 4 at the column level, than it is not possible to distinguish
> between 5.000 and 5. on a per-value basis within that column. If the
> scale at the col
On Fri, Sep 6, 2013 at 11:47 AM, Tom Lane wrote:
> Robert Haas writes:
> > Sure, but the point is that 5. is not the same as 5.000 today. If
> > you start whacking this around you'll be changing that behavior, I
> > think.
>
> Yeah. And please note that no matter what the OP may think, a l
On 9/5/13 10:47 PM, Noah Misch wrote:
On Thu, Sep 05, 2013 at 10:41:25AM -0700, Jeff Janes wrote:
In order to avoid the rewrite, the code would have to be changed to
look up the column definition and if it specifies the scale, then
ignore the per-row n_header, and look at the n_header only if th
On Fri, Sep 6, 2013 at 2:34 PM, Hannu Krosing wrote:
> On 09/06/2013 07:57 PM, Robert Haas wrote:
>> On Fri, Sep 6, 2013 at 12:34 PM, Greg Stark wrote:
>>> But I wonder if we could just declare that that's not what the scale typmod
>>> does. That it's just a maximum scale but it's perfectly valid
Jim Nasby escribió:
> I also have a vague memory of some features that would benefit from
> being able to have typemod info available at a tuple level in a table,
> not just for the entire table. Unfortunately I can't remember why we
> wanted that... (Alvaro, do you recall? I'm pretty sure it's so
On Fri, Sep 6, 2013 at 9:34 AM, Greg Stark wrote:
>
>
> But I wonder if we could just declare that that's not what the scale typmod
> does. That it's just a maximum scale but it's perfectly valid for NUMERIC
> data with lower scales to be stored in a column than the typmod says. In a
> way the cur
Greg Stark writes:
> But I wonder if we could just declare that that's not what the scale typmod
> does. That it's just a maximum scale but it's perfectly valid for NUMERIC
> data with lower scales to be stored in a column than the typmod says. In a
> way the current behaviour is like bpchar but i
Robert Haas writes:
> Sure, but the point is that 5. is not the same as 5.000 today. If
> you start whacking this around you'll be changing that behavior, I
> think.
Yeah. And please note that no matter what the OP may think, a lot of
people *do* consider that there's a useful distinction b
On Fri, Sep 6, 2013 at 12:34 PM, Greg Stark wrote:
> But I wonder if we could just declare that that's not what the scale typmod
> does. That it's just a maximum scale but it's perfectly valid for NUMERIC
> data with lower scales to be stored in a column than the typmod says. In a
> way the curren
On 09/06/2013 07:57 PM, Robert Haas wrote:
> On Fri, Sep 6, 2013 at 12:34 PM, Greg Stark wrote:
>> But I wonder if we could just declare that that's not what the scale typmod
>> does. That it's just a maximum scale but it's perfectly valid for NUMERIC
>> data with lower scales to be stored in a co
On Thu, Sep 5, 2013 at 8:53 PM, Alvaro Herrera wrote:
> Greg Stark escribió:
>
> > The main difficulty is that Postgres is very extensible. So to implement
> > this you need to think bigger than NUMERIC. It should also be possible to
> > alter a column from varchar(5) to varchar(10) for example (b
于 2013-09-06 01:41, Jeff Janes 回复:
On Wed, Sep 4, 2013 at 10:06 PM, wrote:
于 2013-09-04 23:41, Jeff Janes 回复:
On Tue, Sep 3, 2013 at 9:08 PM, wrote:
Hi, Hackers!
I find that it takes a long time when I increase the scale of a
numeric
datatype.
By checking the code, I found that's beca
On Thu, Sep 05, 2013 at 10:41:25AM -0700, Jeff Janes wrote:
> In order to avoid the rewrite, the code would have to be changed to
> look up the column definition and if it specifies the scale, then
> ignore the per-row n_header, and look at the n_header only if the
> column is NUMERIC with no preci
Greg Stark escribió:
> The main difficulty is that Postgres is very extensible. So to implement
> this you need to think bigger than NUMERIC. It should also be possible to
> alter a column from varchar(5) to varchar(10) for example (but not the
> other way around).
We already allow that. See com
On Thu, Sep 5, 2013 at 6:41 PM, Jeff Janes wrote:
> Then if the column was
> altered from NUMERIC with scale to be a plain NUMERIC, it would have
> to rewrite the table to enforce the row-wise scale to match the old
> column-wise scale. Where as now that alter doesn't need a re-write.
> I don't
On Wed, Sep 4, 2013 at 10:06 PM, wrote:
> 于 2013-09-04 23:41, Jeff Janes 回复:
>
>> On Tue, Sep 3, 2013 at 9:08 PM, wrote:
>>>
>>> Hi, Hackers!
>>>
>>> I find that it takes a long time when I increase the scale of a numeric
>>> datatype.
>>> By checking the code, I found that's because it needs t
于 2013-09-04 23:41, Jeff Janes 回复:
On Tue, Sep 3, 2013 at 9:08 PM, wrote:
Hi, Hackers!
I find that it takes a long time when I increase the scale of a
numeric
datatype.
By checking the code, I found that's because it needs to rewrite
that
table's file.
After checking that table's data fil
On Tue, Sep 3, 2013 at 9:08 PM, wrote:
> Hi, Hackers!
>
> I find that it takes a long time when I increase the scale of a numeric
> datatype.
> By checking the code, I found that's because it needs to rewrite that
> table's file.
> After checking that table's data file, I found only parameter n_h
Hi, Hackers!
I find that it takes a long time when I increase the scale of a numeric
datatype.
By checking the code, I found that's because it needs to rewrite that
table's file.
After checking that table's data file, I found only parameter n_header
changed.
And, I found the data in that nume
19 matches
Mail list logo
