Re: On hardcoded type aliases and typmod for user types

On Wed, Aug 31, 2005 at 05:14:13PM -0400, Tom Lane wrote:
> That strikes me as an unnecessary reduction in flexibility.  As long as
> we make the hardwired type names translate to qualified names (same as
> they do now) we don't have to assume any such thing.

Ack, there's fortunatly only a handful of those.

> The point about character sets is a bit distressing; here we are
> designing a new general-purpose mechanism and we can already see
> cases it doesn't handle.  Can we fix that?

Err, well. My thought was a certain group of type-suffix options would
be permitted (only zero or one at a time), for example:
  WITH TIME ZONE  WITHOUT TIME ZONE  CHARACTER SET xxx

And have the grammer accept these after any type. For example, the type
NUMERIC WITH TIME ZONE would be syntactically valid but the code would
then reject it. You have a issue then because the typmod function
should then be able to return a completely different type because the
system looked up "timestamp" and now the function determines that with
that option, it should actually be "timestamptz".

As for the specific mechanism, well, my options were (in the TYPE
declaration statement:
  TYPMODFUNC = function( intarray [, sometype] ) RETURNS int32 or intarray

This restricts the arguments between the brackets to integers, is this
reasonable? The sometype would be something to handle the suffix
options. (Text pair? option,value). Returning an intarray if a new type
is allowed.
  TYPMODFUNC = function( recordtype [, sometype ] ) RETURNS int32 or intarray

The record type could then indicate what's supported, except you can't
pass a variable number of arguments (for NUMERIC). How about fill up
from the front, leave NULLs for all the unfilled ones. The STRICT flag
could tell if all fields need to be filled (ugh).
  TYPMODFUNC = function( internal [, sometype ] ) RETURNS int32 or intarray

Simply pass the (Node*) from the parser and let the function sort it
out itself. Except now they have to be written in C. Is this
unreasonable, it's called fairly early on, all the issues with no valid
snapshot apply here and you can't defer the evaluation till later.

I'm not sure how to choose, they all handle the current situation fine
but what do we want to allow users to do in the future? Is the SQL
standard likely to come up with SOMETYPE(ident) as a declaration, in
which case we need the second or third options. Ident can be converted
to a constant string for these purposes.

And then there's output to consider, currently timestamp etc have
special cases. But if you're going to allow "CHARACTER SET xxx" to
apply to any type, you need a way to reconstruct the values for output.
Requireing the user the provide an inverse function is one (possibly
unreliable) way. Storing the arguments directly is another. And is one
int32 typmod sufficient? This character set per column has been talked
about for a while, but where was the information going to be stored?

There's several issues to be sorted out yet, I fear.

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.