Re: Typmod for user-defined types

AIUI, the issue is statements like:

# select numeric(6,3) '5.6';

Bison can't look far enough ahead to determine whether the numeric is a
type or a function. However, the desired grammer itself is not
ambgiuous, it's just that Bison is not smart enough to make it work. It
works now only because we hardwire the types that are allowed to have
argument.

Wouldn't a way around this be that to have grammer allow a type to look
like a function call but convert the FuncExpr node to a TypeName node
if the grammer determines it is a type after all. Something like:

SimpleTypename: type_name { $$ = $1 }
| func_expr { $$ = MakeTypeFromFuncCall( $1 ) }

That function could then check that only constant integer arguments have been
used, and then dispatch to a type specific function to turn the arg
list into a typmod. Among other things, this would allow us to produce
better error messages for things like bit(6,3) and numeric(l) instead
of just "syntax error".

I was thinking of adding to each type a typmod_in and a typmod_out
function. The first takes an array of integer in and returns an int32,
the latter does the reverse.

This is however quite a dramatic overhaul of the grammer and I'm not
sure it's actually conflict free. But "numeric", "float", "decimal",
etc would no longer need to be matched by the lexer and you could call
the timestamp function without double quotes.

At least in preliminary tests it seems OUT as a function name would be
a casualty due to the new IO/OUT parameters:

function ( field IN OUT type )

It can't determine soon enough that OUT can't be a type in this
context. And with this change type/function names would be the same
list. I wonder if there is a way around this.

Anyway, I'll try out some more stuff.

Have a nice day,

On Sat, Aug 27, 2005 at 11:09:09AM -0400, Tom Lane wrote:
> Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> > Tom Lanes patch[2] looks like it may work, but would a mechanism to
> > allow user-defined types to have a typmod function be accepted?
> > [2] http://archives.postgresql.org/pgsql-hackers/2004-06/msg00932.php
>
> Well, the question still stands: are we going to paint ourselves into
> a corner by requiring type and function names to be equivalent?
>
> regards, tom lane

--
Martijn van Oosterhout <kleptog(at)svana(dot)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.