Skip site navigation (1) Skip section navigation (2)

Re: Syntax for partitioning

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Syntax for partitioning
Date: 2009-10-30 21:39:51
Message-ID: 603c8f070910301439w16c2787bqab1bbf628a1ff2c2@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, Oct 30, 2009 at 5:16 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Jeff Davis <pgsql(at)j-davis(dot)com> writes:
>> I haven't looked at all of these places yet, so maybe a few simple
>> changes would allow us to treat typmod as a full 32 bits. Or perhaps it
>> could just be expanded to a signed 64-bit int. What do you think?
>
> Neither is likely to happen, and even disregarding that, I doubt people
> would be real happy with a design like this.  Where are you going to
> put the typmod for the contained type?

IMO, the real problem is that the type interface is poorly
encapsulated.  There's way too much code that knows about the internal
details of a type - namely, that it's a 32-bit integer modified by a
second 32-bit integer.  I think there are still places where the code
doesn't even know about typmod.  If we're going to go to the trouble
of changing anything, I think it should probably involve inserting an
abstraction layer that will make future extensions easier.  But I have
a feeling that's going to be a tough sell.

...Robert

In response to

Responses

pgsql-hackers by date

Next:From: Jeff DavisDate: 2009-10-30 22:28:29
Subject: Re: Syntax for partitioning
Previous:From: Tom LaneDate: 2009-10-30 21:16:16
Subject: Re: Syntax for partitioning

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group