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
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 |