Re: SQL99, CREATE CAST, and initdb - Mailing list pgsql-hackers

From Tom Lane
Subject Re: SQL99, CREATE CAST, and initdb
Date
Msg-id 7931.1025018083@sss.pgh.pa.us
Whole thread Raw
In response to Re: SQL99, CREATE CAST, and initdb  (Thomas Lockhart <lockhart@fourpalms.org>)
List pgsql-hackers
Thomas Lockhart <lockhart@fourpalms.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




pgsql-hackers by date:

Previous
From: Dave Cramer
Date:
Subject: Re: Democracy and organisation : let's make a revolution
Next
From: Thomas Lockhart
Date:
Subject: Re: Suggestions for implementing IS DISTINCT FROM?