Typed tables

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Typed tables
Date: 2009-11-05 17:24:43
Message-ID: 1257441883.11856.15.camel@vanquo.pezone.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I'm planning to work on typed tables support. The idea is that you
create a table out of a composite type (as opposed to the other way
around, which is currently done automatically).

CREATE TYPE persons_type AS (name text, bdate date);

CREATE TABLE persons OF persons_type;

Or the fancy version:

CREATE TABLE persons OF persons_type ( PRIMARY KEY (name) );

This is useful in conjunction with PL/Proxy and similar RPC-type setups.
On the frontend/proxy instances you only create the type, and the
backend instances you create the storage for the type, and the database
system would give you a little support keeping them in sync. Think
interface and implementation.

We have all the necessary bits available in the PostgreSQL system
already; they just need to be wired together a little differently for
this feature. The CREATE TABLE / OF command would use some parts of the
LIKE and/or INHERITS logic to make a copy of the composite type's
structure, and then we'd probably need a new column in pg_class to store
the relationship of the table to its type.

One thing I'm not sure of is whether to keep the implicit row type in
that case. That is, would the above command sequence still create a
"persons" type? We could keep that so as to preserve the property "a
table always has a row type of the same name", or we could skip it in
that case, so if you create a typed table in this sense, you need to use
the type that you created yourself beforehand.

Thoughts?

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David E. Wheeler 2009-11-05 17:25:07 Re: operator exclusion constraints
Previous Message Jan Wieck 2009-11-05 15:55:39 Re: Shall we just get rid of plpgsql's RENAME?