> > How are you getting handleTargetColname() /
> > checkTargetTypes() called where it is rejecting things?
OK, I'm not sure why the behavior is different if I explicitly specify
the columns (which of course I had for testing):
postgres=> insert into t2 select a from t1;
INSERT 0 0
postgres=> insert into t2 select * from t1;
ERROR: Length of 'a' is not equal to the length of target column 'a'
> It doesn't produce any problems so far, only that the
> function numeric(num,typmod) isn't called when doing a plain
> INSERT ... SELECT.
Hmm. Even when you explicitly specify the columns as I did in my example
above? I should be able to get the wildcard example to work sometime
before v6.5, and I *think* that the explicit cases should do what you
want. As a loadable module, your data type will only match itself for
type coersion, but that's what you want for now. When it is built in,
then you will be able to specify that it is higher or lower in a
heirarchy with, for example, int4 and float8.
> Maybe I have to hook for NUMERIC there in parse_relation too.
> Up to now I'm compiling the whole thing as loadable module.
> I'll check it that's possible when moving it to the builtins.
Unless you can't find a test case which does work for you, don't bother
looking at it; I'll pick it up some time soon.
> But in general I think if there is a function with the same
> name as a type, that take this type plus another int4
> argument, this must be a range checker/padder/truncator or
> the like and it should be called before values are assigned
> to attributes.
That's how it should work afaik, at least for variable-length types. Not
all types are checked for this conversion function...
- Tom
