Re: Namespace issues

From: Don Y <pgsql(at)DakotaCom(dot)Net>
To: kleptog(at)svana(dot)org, pgsql-general(at)postgresql(dot)org
Subject: Re: Namespace issues
Date: 2006-05-16 17:53:10
Message-ID: 446A1186.3040600@DakotaCom.Net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Martijn van Oosterhout wrote:
> On Tue, May 16, 2006 at 10:29:27AM -0700, Don Y wrote:
>> Given a user defined type foo...
>> I've created several casts to/from foo and built-in types.
>> I had adopted a naming convention of:
>> baz foo_to_baz(foo);
>> foo foo_from_baz(baz);
>>
>> But:
>
> <snip>
>
>> I don't see how I can do this in my declarations. E.g.,
>> if I have
>> baz = {int4, text, float8, ...}
>> then I end up with several (C) functions all named foo()
>> but each taking a different argument type (baz). Since
>> C doesn't support more than a single namespace for functions,
>> this just won't work.
>>
>> What am I failing to see, here?
>
> That the name of the function in C doesn't have to be the same as the
> name of the function in SQL. You can even define many SQL functions
> that all refer to the same C function.
>
> So in your C file yo call them:
>
> cast_foo_to_baz()
>
> and in the SQL you declare as just:
>
> baz()

But what *binds* my C declaration to the corresponding SQL
"CREATE CAST"?

E.g.,

CREATE FUNCTION foo_from_baz(baz)
RETURNS foo
AS '...'
LANGUAGE 'C' IMMUTABLE STRICT;

yet, to support the foo(baz) syntax, I would then need (?)
to continue with:

CREATE CAST (baz AS foo)
WITH FUNCTION foo(baz);

or, do I use:

CREATE CAST (baz as foo)
WITH FUNCTION foo_from_baz(baz);

but then how does the "foo(baz)" syntax originate?
or, is this a built in "feature" of the interpreter?
(In which case, why all the commentary <snip>ed that
tells me to name my functions in this way?)

--don

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Martijn van Oosterhout 2006-05-16 18:02:59 Re: Namespace issues
Previous Message Kenneth Downs 2006-05-16 17:40:44 Re: best practice in upgrading db structure