Greg Stark writes:
> Fwiw I think he's right that sum(int2) should perhaps be redefined to
> return int8. As it stands all it would take is a 64k rows to
> potentially overflow. It's not super likely but it is plausible and
> the performance penalty to use int8 wouldn't be super big either.
It's
On Sun, Nov 14, 2010 at 9:16 PM, Greg Stark wrote:
> On Sun, Nov 14, 2010 at 11:15 AM, Daniel Farina wrote:
>> SUM(int2) => int4
>> SUM(int4) => int8
>> SUM(int8) => numeric
>>
>> Some weaknesses:
>>
>> SUM, of any precision, assumes that the precision being accumulated
>> into (which is also the
On Sun, Nov 14, 2010 at 11:15 AM, Daniel Farina wrote:
> SUM(int2) => int4
> SUM(int4) => int8
> SUM(int8) => numeric
>
> Some weaknesses:
>
> SUM, of any precision, assumes that the precision being accumulated
> into (which is also the return-precision) is enough to avoid overflow.
> This is gene
Daniel Farina writes:
> There are other ways one might be able to attack the performance part
> of the problem, but consider the loss of information about the type
> from int(2|4|8) to numeric when composing a series of sums: we know
> the value produced fits the abstract notion of an Integer, but
On Sun, Nov 14, 2010 at 1:25 PM, Robert Haas wrote:
> Like Tom, I'm not sure this is really a type-system problem. This
> sounds like a complaint that operations on "numeric" are much slower
> than operations on "int4" and "int8", even for values that could be
> represented by either type. I thi
On Sun, Nov 14, 2010 at 2:27 PM, Daniel Farina wrote:
> On Sun, Nov 14, 2010 at 7:47 AM, Tom Lane wrote:
>> Daniel Farina writes:
>>> Here are some weaknesses in the SUM aggregate that run up against the
>>> type system. Maybe they'll help crystallize some discussion:
>>
>>> SUM(int2) => int4
>>
Daniel Farina wrote:
On Sat, Nov 13, 2010 at 7:54 PM, Darren Duncan wrote:
You don't have to kludge things by implementing arrays as blobs for example;
you can implement them as relations instead. Geospatial types can just be
tuples. Arrays of structured types can just be relations with an att
On Sun, Nov 14, 2010 at 7:47 AM, Tom Lane wrote:
> Daniel Farina writes:
>> Here are some weaknesses in the SUM aggregate that run up against the
>> type system. Maybe they'll help crystallize some discussion:
>
>> SUM(int2) => int4
>> SUM(int4) => int8
>> SUM(int8) => numeric
>
>> Some weaknesse
Daniel Farina writes:
> Here are some weaknesses in the SUM aggregate that run up against the
> type system. Maybe they'll help crystallize some discussion:
> SUM(int2) => int4
> SUM(int4) => int8
> SUM(int8) => numeric
> Some weaknesses:
> SUM, of any precision, assumes that the precision bein
On Fri, Nov 12, 2010 at 4:07 PM, Jeff Davis wrote:
> I think the best we'll do is be able to hack on some of the things that
> we actively want and have clear use cases for, such as type interfaces.
> We might have to give up on some of the more ambitious ideas that
> involve propagating interesti
On Sat, Nov 13, 2010 at 7:54 PM, Darren Duncan wrote:
> A key component of a good type system is that users can define data types,
> and moreover where possible, system-defined types are defined in the same
> ways as users define types. For example, stuff like temporal types or
> geospatial types
David Fetter wrote:
For the past couple of years, I've been hearing from the PostGIS
people among others that our type system just isn't flexible enough
for their needs. It's really starting to show its age, or possibly
design compromises that seemed reasonable a decade or more ago, but
are less
On 11/12/2010 07:07 PM, Jeff Davis wrote:
On Fri, 2010-11-12 at 08:34 -0800, David Fetter wrote:
Folks,
For the past couple of years, I've been hearing from the PostGIS
people among others that our type system just isn't flexible enough
for their needs. It's really starting to show its age,
On Fri, 2010-11-12 at 08:34 -0800, David Fetter wrote:
> Folks,
>
> For the past couple of years, I've been hearing from the PostGIS
> people among others that our type system just isn't flexible enough
> for their needs. It's really starting to show its age, or possibly
> design compromises that
On Fri, Nov 12, 2010 at 6:12 PM, Jeff Davis wrote:
> That being said, a few details are left to be decided (an
> understatement).
Best... comment... ever.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-h
On Fri, 2010-11-12 at 12:03 -0500, Andrew Dunstan wrote:
>
> On 11/12/2010 11:34 AM, David Fetter wrote:
> > Folks,
> >
> > For the past couple of years, I've been hearing from the PostGIS
> > people among others that our type system just isn't flexible enough
> > for their needs. It's really sta
Andrew Dunstan writes:
> This is so general as to be quite meaningless to me. What is it that is
> wanted that we don't have. (And don't say "flexibility", that's way too
> general - say something much more concrete and specific. If you want
> flexibility we can store everything as text, but I dou
On 11/12/2010 11:34 AM, David Fetter wrote:
Folks,
For the past couple of years, I've been hearing from the PostGIS
people among others that our type system just isn't flexible enough
for their needs. It's really starting to show its age, or possibly
design compromises that seemed reasonable
Folks,
For the past couple of years, I've been hearing from the PostGIS
people among others that our type system just isn't flexible enough
for their needs. It's really starting to show its age, or possibly
design compromises that seemed reasonable a decade or more ago, but
are less so now.
To t
19 matches
Mail list logo
