Re: SQL99, CREATE CAST, and initdb

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

In response to

Responses

Browse pgsql-hackers by date

  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