From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Thomas Lockhart <lockhart(at)fourpalms(dot)org> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL Hackers List <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: SQL99, CREATE CAST, and initdb |
Date: | 2002-06-25 15:14:43 |
Message-ID: | 7931.1025018083@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thomas Lockhart <lockhart(at)fourpalms(dot)org> writes:
>> 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.
Well, let's see an alternate proposal.
> 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.
If we just look for "anything named int4() in the current search path"
then I think we will have some unpleasantnesses of a different sort,
namely unexpected conflicts between similarly-named types in different
schemas.
> btw, how *do* I control the default schema? Is it always the schema at
> the front of the search list,
If you mean the default schema for creating things, yes, it's whatever
is at the front of the search list. Should it be different?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Lockhart | 2002-06-25 15:19:04 | Re: Suggestions for implementing IS DISTINCT FROM? |
Previous Message | Dave Cramer | 2002-06-25 15:12:57 | Re: Democracy and organisation : let's make a revolution |