Обсуждение: SPI - couple things (7.0.2)

Last night, I attempted to access the data of several TEXT parameters into a
'language 'C'' function I've created and got an interesting result...  on of
the strings gets a little garbled on the end...  I haven't attempted to
debug it yet (isoloate the behaviour; gave up; went home) but I"m wondering
if it can be assumed that the (char *) part of the TEXT struct (VARDATA) has
been terminated at the length specified by the (VARLEN())?? part. What I'm
passing is a TEXT field containing a unix filesystem path, and there seems
to be either a couple chars added on the end, or the last couple char of the
path are unprintable type things... (possibly a backspace character at the
end?)

question #2... W.R.T. creating the function stub in a database,

CREATE FUNCTION test_func (text) returns int4 as
'/usr/local/pgsql/cfunc.so', 'cfunc' LANGUAGE 'C';

pg_dump doesn't seem to include the extra 'cfunc' in the output of this
line... this is an annoyance as everytime i use pgdump to move the database
over to another machine, i have to edit this back in before sucking it in
through psql.
so the question is, "what's up with this?" 8)

thanks
Scott.

"Scott Muir" <wsmuir@islandnet.com> writes:
> Last night, I attempted to access the data of several TEXT parameters into a
> 'language 'C'' function I've created and got an interesting result...  on of
> the strings gets a little garbled on the end...  I haven't attempted to
> debug it yet (isoloate the behaviour; gave up; went home) but I"m wondering
> if it can be assumed that the (char *) part of the TEXT struct (VARDATA) has
> been terminated at the length specified by the (VARLEN())?? part.

TEXT data is guaranteed *not* to be null terminated.  If you are
writing code that expects it to be, you will have lots of problems.
        regards, tom lane

> ...the strings gets a little garbled on the end...

The length *includes* the header length. You are likely reading over the
end of the string? Or you are expecting it to be null terminated, per
Tom Lane's comment.
                      - Thomas