Thread: Doccumentation Patch for Create Function

Hi all,

Please find attached diffs to the documentation that are intended to
accompany the CREATE FUNCTION patch that I submitted earlier.  I stuck
with the syntax in the original patch rather than the alternative
syntax suggested by Andreas.

When I was altering the xfunc.sgml page I came across this:

      <title>Name Space Conflicts</title>

      <para>
      As of <productname>Postgres</productname> v6.5,
      <command>CREATE FUNCTION</command> can decouple a C language
      function name from the name of the entry point. This is now the
      preferred technique to accomplish function overloading.
      </para>

which seems to suggest that someone had a similar idea in the past.  I
could find no evidence of this functionality in the 6.5 code though

Bernard Frankpitt

Applied Docs too.


> Hi all,
> 
> Please find attached diffs to the documentation that are intended to
> accompany the CREATE FUNCTION patch that I submitted earlier.  I stuck
> with the syntax in the original patch rather than the alternative
> syntax suggested by Andreas. 
> 
> When I was altering the xfunc.sgml page I came across this:
> 
>       <title>Name Space Conflicts</title>
>   
>       <para>
>       As of <productname>Postgres</productname> v6.5,
>       <command>CREATE FUNCTION</command> can decouple a C language
>       function name from the name of the entry point. This is now the
>       preferred technique to accomplish function overloading.
>       </para>
> 
> which seems to suggest that someone had a similar idea in the past.  I
> could find no evidence of this functionality in the 6.5 code though
> 
> Bernard Frankpitt

[Attachment, skipping...]


--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 

Bernard Frankpitt <frankpit@pop.dn.net> wrote (a couple weeks ago):
> When I was altering the xfunc.sgml page I came across this:

>       <title>Name Space Conflicts</title>
>       <para>
>       As of <productname>Postgres</productname> v6.5,
>       <command>CREATE FUNCTION</command> can decouple a C language
>       function name from the name of the entry point. This is now the
>       preferred technique to accomplish function overloading.
>       </para>

> which seems to suggest that someone had a similar idea in the past.  I
> could find no evidence of this functionality in the 6.5 code though

That's talking about builtin functions, ie functions implemented by
statically-linked routines in the standard backend.  The SQL name is
now distinct from the C-language name, but that wasn't true before 6.5.
I kind of thought you had seen this and realized it would be a good
idea to have the same functionality for dynamically linked routines.

If you came up with the idea independently, it must clearly be a good
thing ;-)
        regards, tom lane

Tom Lane wrote:
> 
> Bernard Frankpitt <frankpit@pop.dn.net> wrote (a couple weeks ago):
> > When I was altering the xfunc.sgml page I came across this:
> 
>      "     "     "
> >
> That's talking about builtin functions, ie functions implemented by
> statically-linked routines in the standard backend. 
> 
>                         regards, tom lane

Oh,  That explains it.  It didn't occur to me that people adding custom 
functionality to the backend wouldn't use a dynamically linked
interface.  In fact it occured to me that it might be a good idea to
convert some of `poor relations' the stuff like gist, and perhaps rtrees
to dynamically linked modules in /contrib. They might then provide
better examples of how to develop and link major extensions into the
backend in a relatively painless way.  Also an exercise like that would
really provide a good opportunity to define and document the backend
code interfaces between the executor and access methods, and between
access methods and the low-level database functionality (buffer
management, tuple time-validation etc.).  Once I finish my dissertation,
I was sort of planning to start chipping away at some documentation for
the code internals.  

To me, the extensibility features and open design of PostgreSQL are its
most exciting features, and I think that a good set of documents on the
internal functionality and interfaces would be rewarded in the long term
by innovative features and unusual applications from developers in a
wide variety of fields. 

Bernie