Re: text datum VARDATA and strings
От | Reece Hart |
---|---|
Тема | Re: text datum VARDATA and strings |
Дата | |
Msg-id | 1155593509.4158.134.camel@tallac.gene.com обсуждение исходный текст |
Ответ на | Re: text datum VARDATA and strings (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-general |
On Mon, 2006-08-14 at 15:51 -0400, Tom Lane wrote:
The PostgreSQL manual. I wrote these functions early in the 7.x series and I don't know which manual version exactly. For example, the sec 9.5.4 of
http://www.postgresql.org/docs/7.3/static/xfunc-c.html shows code for concat_text, which I remember was the basis for what I wrote. I now see and understand the text regarding detoasting the 'DatumGetXXX' macros; the relevance of these were not obvious to me at the time.
Okay. Does that mean that code in 9.5.4 should have a warning to that effect?
Okay. Thanks for the advice, Tom.
-Reece
Whose 7.x manual? This stuff has been there since we invented the "version 1" function call convention, which was 7.3 or before. There is some documentation in the SGML docs, but really we kind of expect you to look at the standard built-in functions to see how things are done...
The PostgreSQL manual. I wrote these functions early in the 7.x series and I don't know which manual version exactly. For example, the sec 9.5.4 of
http://www.postgresql.org/docs/7.3/static/xfunc-c.html shows code for concat_text, which I remember was the basis for what I wrote. I now see and understand the text regarding detoasting the 'DatumGetXXX' macros; the relevance of these were not obvious to me at the time.
So it's best not to assume that you know what is inside a text datum, if possible,
Okay. Does that mean that code in 9.5.4 should have a warning to that effect?
> 3) Is there any reason to believe that the code below is problematic? The only thing I'd suggest is that checking for a null return from palloc is a waste of effort. It doesn't return to you if it runs out of memory.
Okay. Thanks for the advice, Tom.
-Reece
-- Reece Hart, http://harts.net/reece/, GPG:0x25EC91A0 |
В списке pgsql-general по дате отправления: