Re: %TYPE

From: Michael Glaesemann <grzm(at)seespotcode(dot)net>
To: Ged <pgsql4gm(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: %TYPE
Date: 2007-08-23 04:00:41
Message-ID: 55D672B2-41CB-4CA7-9585-628F486F2108@seespotcode.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


On Aug 22, 2007, at 21:42 , Ged wrote:

> I've been looking to see if postgresql allows type definitions like
> the ones I'm used to from Oracle, where I can say:
>
> CREATE TYPE npc_page_details_type AS
> (
> ...
> instance_name instances.name%type,
> ...
> );
>
> and it will pick up the current type of instances.name when the user
> type gets compiled.

I think you could use domains for something like this.

CREATE DOMAIN instance_name_type AS character varying;

And then use the domain in your types.

CREATE TYPE npc_page_details_type AS
(
instance_name instance_name_type
);

CREATE table publications
(
name instance_name_type PRIMARY KEY
);

However, in this particular case I don't see the point. There is no
performance advantage to using varchar(n) over just plain varchar or
the PostgreSQL type text, which although nonstandard tends to be more
common among developers used to PostgreSQL. Only if you have a
specific business reason that these columns absolutely must not have
more than x number of characters should you use varchar(n). Otherwise
you're going to be changing data types every time you want to change
the limit which is not all that much fun.

Michael Glaesemann
grzm seespotcode net

In response to

  • %TYPE at 2007-08-23 02:42:24 from Ged

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2007-08-23 04:21:00 Re: ERROR: could not open relation with OID
Previous Message Greg Smith 2007-08-23 03:56:55 Re: Postgres, fsync and RAID controller with 100M of internal cache & dedicated battery