On Sat, Nov 13, 2010 at 7:54 PM, Darren Duncan dar...@darrenduncan.net 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
On Fri, Nov 12, 2010 at 4:07 PM, Jeff Davis pg...@j-davis.com 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
Daniel Farina drfar...@acm.org 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
On Sun, Nov 14, 2010 at 7:47 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Daniel Farina drfar...@acm.org 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
Daniel Farina wrote:
On Sat, Nov 13, 2010 at 7:54 PM, Darren Duncan dar...@darrenduncan.net 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
On Sun, Nov 14, 2010 at 2:27 PM, Daniel Farina drfar...@acm.org wrote:
On Sun, Nov 14, 2010 at 7:47 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Daniel Farina drfar...@acm.org writes:
Here are some weaknesses in the SUM aggregate that run up against the
type system. Maybe they'll help crystallize
On Sun, Nov 14, 2010 at 1:25 PM, Robert Haas robertmh...@gmail.com 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
Daniel Farina drfar...@acm.org 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
On Sun, Nov 14, 2010 at 11:15 AM, Daniel Farina drfar...@acm.org 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
On Sun, Nov 14, 2010 at 9:16 PM, Greg Stark gsst...@mit.edu wrote:
On Sun, Nov 14, 2010 at 11:15 AM, Daniel Farina drfar...@acm.org wrote:
SUM(int2) = int4
SUM(int4) = int8
SUM(int8) = numeric
Some weaknesses:
SUM, of any precision, assumes that the precision being accumulated
into (which
Greg Stark gsst...@mit.edu 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
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
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
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
Andrew Dunstan and...@dunslane.net 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
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 starting to
On Fri, Nov 12, 2010 at 6:12 PM, Jeff Davis pg...@j-davis.com 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
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 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,
19 matches
Mail list logo
