From: Tom Lane <tgl@sss.pgh.pa.us>
To: Albe Laurenz <laurenz.albe@wien.gv.at>
cc: "Ferrell, Denise CTR NSWCDD, Z11 *EXTERN*" <denise.ferrell.ctr@navy.mil>,
 "pgsql-admin@postgresql.org" <pgsql-admin@postgresql.org>
Subject: Re: PK/FK impacts using text data type
In-reply-to: 
 <A737B7A37273E048B164557ADEF4A58B34E5C673@ntex2010a.host.magwien.gv.at>
References: 
 <2BC18916DE4BF141AC1EFC55CE2CAE7D614327@NAEANRFKXM01V.nadsusea.nads.navy.mil>
 <A737B7A37273E048B164557ADEF4A58B34E5C673@ntex2010a.host.magwien.gv.at>
Comments: In-reply-to Albe Laurenz <laurenz.albe@wien.gv.at>
 message dated "Sat, 10 Jan 2015 19:14:09 +0000"
Date: Sat, 10 Jan 2015 14:20:50 -0500
Message-ID: <23199.1420917650@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-admin-owner@postgresql.org

Albe Laurenz <laurenz.albe@wien.gv.at> writes:
> The only useful thing about varchar is that it imposes a length constraint on a database field.

> Values used for indexing have a length limit, so if you change an indexed column to text
> somebody could try to insert values that will cause errors because the limit has been exceeded.

I'm not particularly buying that argument.  If you insert an overlength
field value, you will get an error either way; it's just spelled
differently.  Also, using varchar(N) isn't a particularly efficient way to
guard the btree length limit, because N is measured in characters but the
btree length limit is in bytes.  You'd have to use a very conservatively
small N to be absolutely sure you don't get a btree error, and that would
result in throwing some errors that actually weren't necessary at all.

> Also you application code cannot rely on a certain size limit any more.

This is a valid argument, though again only to the extent that you need a
size limit measured in characters not bytes.

			regards, tom lane


-- 
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin