From: | Bernard Frankpitt <frankpit(at)pop(dot)dn(dot)net> |
---|---|
To: | Andreas Zeugswetter <andreas(dot)zeugswetter(at)telecom(dot)at>, hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Patch for user-defined C-language functions |
Date: | 1999-09-14 15:47:14 |
Message-ID: | 37DE6E02.32E4B3AD@pop.dn.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andreas Zeugswetter wrote:
>
> But I think the intuitive Syntax in SQL would use ():
>
> CREATE FUNCTION mytype3 ( mytype2 )
> RETURNS mytype3
> AS 'mytypes.so(mytype2_to_mytype3)'
> LANGUAGE 'C'
>
> Syntax:
> AS <link_file>[(symbol_name)]
>
> This is also how Illustra and now Informix does it.
> (Instead of AS they say EXTERNAL NAME)
>
The syntax
AS <link_file>[(symbol_name)]
would be easy to implement provided I could write your example as
CREATE FUNCTION mytype3 ( mytype2 )
RETURNS mytype3
AS 'mytypes.so'('mytype2_to_mytype3')
LANGUAGE 'C'
That way link_file and symbol_name both look like string tokens to
the parser. If it is implemented the way you write in the example with
'mytypes.so(mytype2_to_mytype3)'
Then the parser sees the arguement of the AS clause as a single
string token which would have to be parsed separately. Also, there is
some ambiguity in this form as to whether the string
'mytypes.so(mytype2_to_mytype3)'
is a single filename, or a filename and a link symbol
Bernie
From | Date | Subject | |
---|---|---|---|
Next Message | Stéphane FILLON | 1999-09-14 16:50:09 | Permission problem with COPY FROM |
Previous Message | Thomas Lockhart | 1999-09-14 15:44:25 | Re: [HACKERS] ISO dates with European Format |