From: Andrew C.R. Martin <a.c.r.martin@reading.ac.uk>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: interfaces@postgresql.org
Cc: docs@postgresql.org
Cc: hackers@postgresql.org
Subject: Re: [HACKERS] Re: Bugs: Programming Language Functions
Date: Thu, 13 Apr 2000 08:52:05 +0100
Message-ID: <00041308564200.29884@sapc13.rdg.ac.uk> (raw)
References: <1708.955474421@sss.pgh.pa.us>
On Tue, 11 Apr 2000, Tom Lane wrote:
> "Andrew C.R. Martin" <a.c.r.martin@reading.ac.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.c.r.martin@reading.ac.uk (work)
Lecturer in Bioinformatics andrew@stagleys.demon.co.uk (home)
University of Reading
Tel.: +44 (0)118 987 5123x7022 Fax: +44 (0)118 931 0180
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: a.c.r.martin@reading.ac.uk, tgl@sss.pgh.pa.us, interfaces@postgresql.org, docs@postgresql.org, hackers@postgresql.org
Subject: Re: [HACKERS] Re: Bugs: Programming Language Functions
In-Reply-To: <00041308564200.29884@sapc13.rdg.ac.uk>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox