On Sat, Jul 08, 2006 at 05:54:26PM -0400, Jim Nasby wrote:
> +1. If there's enough user demand we can look at adding the type to
> core (I don't see any real advantage to contrib over pgFoundry for
> this). I'm not sure if it makes sense to add a generic 16 byte RAW to
> core, either. I'd *much* rather see effort expended on a generic RAW
> type which had it's size defined as part of the type and didn't use
> varlena.
You could place a nice wrapper around type generators, which would let
you say:
DECLARE TYPE RAW(16);
After which point you could use that type in function declarations and
such. It would create an OID for that type would could be used as
normal.
I think that trying to get the backend to pay more attention to typmods
is not going to be successful. Simply because functions and operators
have an affect on the typmod and once you start relying on typmods to
decode a tuple, you've got a real problem.
As an example, what do you get when you concatenate two CHAR(4)'s? Do
you get another CHAR(4) or is it a CHAR(8)? How does the backend know?
You'd have to accompany each function with another function just to
tell you how the typmods would be related.
The only way out I can think of is that RAW(n) is merely a sort of
template and RAW(x) cannot be used in a place where RAW(y) is expected
(if x<>y). Hence it makes sense to have a template that people can
instantiate instances of and let the rest of the system treat them as
new types, unrelated to anything else.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.
