Tweak the API for per-datatype typmodin functions so that they are passed

an array of strings rather than an array of integers, and allow any simple
constant or identifier to be used in typmods; for example
	create table foo (f1 widget(42,'23skidoo',point));
Of course the typmodin function has still got to pack this info into a
non-negative int32 for storage, but it's still a useful improvement in
flexibility, especially considering that you can do nearly anything if you
are willing to keep the info in a side table.  We can get away with this
change since we have not yet released a version providing user-definable
typmods.  Per discussion.

1 files changed, 3 insertions, 3 deletions

diff --git a/src/backend/commands/typecmds.c b/src/backend/commands/typecmds.c
index 5402cde74cd..d9748cf0ea8 100644
--- a/src/backend/commands/typecmds.c
+++ b/src/backend/commands/typecmds.c
@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/commands/typecmds.c,v 1.104 2007/05/12 00:54:59 tgl Exp $
+ *	  $PostgreSQL: pgsql/src/backend/commands/typecmds.c,v 1.105 2007/06/15 20:56:49 tgl Exp $
  *
  * DESCRIPTION
  *	  The "DefineFoo" routines take the parse tree and pick out the
@@ -1270,9 +1270,9 @@ findTypeTypmodinFunction(List *procname)
 	Oid			procOid;
 
 	/*
-	 * typmodin functions always take one int4[] argument and return int4.
+	 * typmodin functions always take one cstring[] argument and return int4.
 	 */
-	argList[0] = INT4ARRAYOID;
+	argList[0] = CSTRINGARRAYOID;
 
 	procOid = LookupFuncName(procname, 1, argList, true);
 	if (!OidIsValid(procOid))