Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
Thread:
Lists: pgsql-docspgsql-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

pgsql-docs by date

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

pgsql-interfaces by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group