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.
signature.asc
Description: Digital signature
