> Another possibility is that you got burnt by some schema-related issue;
> cf the updated conversion docs at
> http://developer.postgresql.org/docs/postgres/typeconv-func.html
I'll bet that is it, though possible differences in CAST() behaviors are
not explained. I'll see if I can reproduce them...
> IIRC, a function is only considered to be a cast function if it matches
> by name *and schema* with the target type. So if you, for example,
> make a function public.int4(something), it'll never be considered a
> cast function for pg_catalog.int4. I had some doubts about that rule
> when I put it in, but so far have not thought of an alternative I like
> better.
Well, istm that we should choose something different. The example I was
using might be a good use case for a situation we should handle: I
implemented a function to convert Unix system time to PG timestamp, and
wanted it to respond to an explicit cast but *not* an implicit cast.
I got it to work at some point (not sure how, given your description of
the schema, uh, scheme) but istm that we definitely do not want to
*require* modifications to pg_catalog for any and every change in
feature or behavior for built-in types. The schema settings are
important, and should have some influence over behavior; that is, if
someone extends PG in one schema then if that schema is in the chain it
should be able to influence the session, and if it is not then it should
only be able to influence the session if there are side-effects from
previous definitions.
btw, how *do* I control the default schema? Is it always the schema at
the front of the search list, or are there other more direct knobs to
help determine this other than explicitly qualifying names in queries?
- Thomas
