Re: RFC for adding typmods to functions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: pgsql-hackers(at)postgreSQL(dot)org, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Subject: Re: RFC for adding typmods to functions
Date: 2009-11-17 23:01:52
Message-ID: 5959.1258498912@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Apart from all these it's not clear to me what the major benefits of
> doing this would be. I'd like an explanation of that to start with.

Well, aside from the issue about making "anyelement" more powerful
(which could be done in other ways), I can think of:

If we don't start down this path then we are never going to satisfy the
spec's expectations about type modifiers (the varchar concatenation
example among others). The given patch doesn't do that or even come
close, but it's a necessary prelude.

More generally, people have complained in the past about typmods being
red-headed stepchildren in the type system. At present, since the
majority of expression forms throw away typmod information, there's
not much hope of treating typmod on the same level as type proper.
(If you look at the history of the expression-tree code you'll notice
that we've gradually propagated typmods into more and more places.
Associating a typmod with function results is the last major holdout.)

I'm not sure that these points fully justify the work involved, but
it certainly seems to be a logical avenue of development if we can
agree on the semantics.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2009-11-17 23:05:19 Re: plperl and inline functions -- first draft
Previous Message Robert Haas 2009-11-17 22:59:42 Re: plpgsql: open for execute - add USING clause