Re: [HACKERS] Re: Bugs: Programming Language Functions
От | Andrew C.R. Martin |
---|---|
Тема | Re: [HACKERS] Re: Bugs: Programming Language Functions |
Дата | |
Msg-id | 00041308564200.29884@sapc13.rdg.ac.uk обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: Bugs: Programming Language Functions (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-docs |
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
В списке pgsql-docs по дате отправления: