Re: [HACKERS] Re: Bugs: Programming Language Functions

From: "Andrew C(dot)R(dot) Martin" <a(dot)c(dot)r(dot)martin(at)reading(dot)ac(dot)uk>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: interfaces(at)postgresql(dot)org, docs(at)postgresql(dot)org, hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Re: Bugs: Programming Language Functions
Date: 2000-04-13 07:52:05
Message-ID: 00041308564200.29884@sapc13.rdg.ac.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs pgsql-interfaces

On Tue, 11 Apr 2000, Tom Lane wrote:
> "Andrew C.R. Martin" <a(dot)c(dot)r(dot)martin(at)reading(dot)ac(dot)uk> writes:
> >> Hm. I'm not too clear on why that would need to worry about either
> >> TupleTableSlot or GetAttributeByName ... shouldn't it be a simple
> >> function consuming a text Datum and producing another?
>
> > Errrmmm, just following the instructions in the docs:
>
> > Programmer's Manual, Chapter 4. Extensing SQL: Functins (page
> > x414.htm), under the C examples.
>
> OK, I see. You've got a function that accepts an entire tuple and
> has hard-wired assumptions about which fields to extract from the tuple.
> Certainly there are cases where that's what's needed, but I'd be
> inclined to define the function as taking two parameters int4 and text*,
> then calling it as myfunc(table.codon, table.substitution). That pushes
> the need for tuple field access out of your code.

Yes that's a good point. I guess 4 years or so ago when I first wrote this bit
of code, I simply followed the instructions in the manual and didn't think
around other ways of doing things

>
> That doesn't affect the validity of your point, of course. We have done
> wholesale renamings of backend types, fields, and functions, as part of
> an ongoing effort to clean up the code; and I expect there will be more
> in future. Perhaps we should pay more attention to not breaking user
> functions unnecessarily when we do this.

Not so much that, but we should make sure that the docs keep pace with such
changes. That to me is more important! I don't mind too much if the user
functions have to be changed, but I'd like the docs to tell me what to do and
things such as this which have been supported previously just from the
.../include path (rather than .../src/include) should remain so :-)

Can we make sure that this becomes a formal item in the TODO lists for code and
docs??

Best wishes,

Andrew

--
Dr. Andrew C.R. Martin EMail: a(dot)c(dot)r(dot)martin(at)reading(dot)ac(dot)uk (work)
Lecturer in Bioinformatics andrew(at)stagleys(dot)demon(dot)co(dot)uk (home)
University of Reading
Tel.: +44 (0)118 987 5123x7022 Fax: +44 (0)118 931 0180

In response to

Responses

Browse pgsql-docs by date

  From Date Subject
Next Message Andrew C.R. Martin 2000-04-13 09:31:58 Re: Re: [HACKERS] Re: Bugs: Programming Language Functions
Previous Message Jan Wieck 2000-04-13 07:33:46 Re: [HACKERS] TODO doc items

Browse pgsql-interfaces by date

  From Date Subject
Next Message Andrew C.R. Martin 2000-04-13 09:31:58 Re: Re: [HACKERS] Re: Bugs: Programming Language Functions
Previous Message Thomas Lockhart 2000-04-13 05:23:52 Re: [GENERAL] Does PGSQL ODBC exist for the Macintosh?