Re: WIP: generalized index constraints

From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Brendan Jurd <direvus(at)gmail(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: WIP: generalized index constraints
Date: 2009-08-21 11:10:49
Message-ID: 2B5A85F5-4F43-4590-AA34-CEC25A2FFA48@hi-media.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Le 21 août 09 à 06:04, Jeff Davis a écrit :
> There is not much of a problem with backwards compatibility. LIKE is
> shorthand (not stored in catalogs), so it doesn't affect
> pg_dump/restore. And hopefully there aren't a lot of apps out there
> creating tables dynamically using the LIKE syntax.

I for one use this a lot, every time I'm doing partitioning. What I do
is a plpgsql function creating partitions for a given period
(create_parts(date, date) and default interval with
create_parts(date)), and the function will EXECUTE something like this:

CREATE TABLE schema.partition_YYYYMM (
LIKE schema.parent INCLUDING DEFAULTS INCLUDING INDEXES INCLUDING
CONSTRAINTS,
CHECK ( partition check expression )
)
INHERITS( schema.parent );

The reason to do this is that inherits won't care at all about the
indexes, defaults and constraints. The drawback to doing it this way
is the cheer number of NOTICEs you get back at inherits time when PG
is so verbose about finding that child already has all the parents
columns. From 8.3 onwards it's possible to trick the system though:

CREATE FUNCTION ... ()
RETURNS ...
LANGUAGE plpgsql
SET client_min_messages TO warning
AS $$
$$;

Regards,
--
dim

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Paul Matthews 2009-08-21 11:42:57 Re: Geometric Elimination
Previous Message Martijn van Oosterhout 2009-08-21 10:51:33 Re: Geometric Elimination