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

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search archives
  Advanced Search

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: Fri, 30 Oct 2009 17:39:51 -0400
  • Message-id: <603c8f070910301439w16c2787bqab1bbf628a1ff2c2@mail.gmail.com> <text/plain>

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



Home | Main Index | Thread Index

Privacy Policy | About PostgreSQL
Copyright © 1996 – 2012 PostgreSQL Global Development Group