>
> extern text *cstring_to_text_with_len(const char *s, int len);
buffer_to_text ???
Regards
Pavel Stehule
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Tom Lane escribió:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
> > A text_to_cstring_with_len() or text_to_cstring_limit() might be more
> > to the point, and more consistent with the other functions in the
> > family.
>
> Hmm. The thing that's bothering me is that the length is the size
> of t
Tom Lane wrote:
> > A text_to_cstring_with_len() or text_to_cstring_limit() might be more
> > to the point, and more consistent with the other functions in the
> > family.
>
> Hmm. The thing that's bothering me is that the length is the size
> of the *destination*, which is not like cstring_to_te
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> On 26/03/2008, Tom Lane <[EMAIL PROTECTED]> wrote:
>> ... What I think is more useful is
>> a strlcpy()-like function that copies into a caller-supplied buffer
>> of limited size. For lack of a better idea I propose defining it
>> *exactly* like strlcpy
On 26/03/2008, Tom Lane <[EMAIL PROTECTED]> wrote:
> Brendan's patch also included "cstring_text_limit(const char *s, int len)"
> which was defined as copying Min(len, strlen(s)) bytes. I didn't find
> this to be particularly useful. In the first place, all potential
> callers are passing the
I've been working some more on Brendan Jurd's patch to simplify text <->
C string conversions. It seems we have consensus on the names for the
base operations:
extern text *cstring_to_text(const char *s);
extern char *text_to_cstring(const text *t);
Brendan's patch also included "cstring_text_li
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>> "Tom Lane" <[EMAIL PROTECTED]> writes:
>>> If there are not additional votes, I'll go with TextPGetCString
>>> and CStringGetTextP.
>>
>> I would have voted for text_to_cstring etc. I can see the logic for the above
>> but it's j
Gregory Stark wrote:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>
> > Volkan YAZICI <[EMAIL PROTECTED]> writes:
> >> But I'd vote for TextPGetCString style Tom suggested for the eye-habit
> >> compatibility with the rest of the code.
> >
> > If there are not additional votes, I'll go with TextPGetCS
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Volkan YAZICI <[EMAIL PROTECTED]> writes:
>> But I'd vote for TextPGetCString style Tom suggested for the eye-habit
>> compatibility with the rest of the code.
>
> If there are not additional votes, I'll go with TextPGetCString
> and CStringGetTextP.
I wou
Volkan YAZICI <[EMAIL PROTECTED]> writes:
> But I'd vote for TextPGetCString style Tom suggested for the eye-habit
> compatibility with the rest of the code.
If there are not additional votes, I'll go with TextPGetCString
and CStringGetTextP.
regards, tom lane
--
Sent vi
On Wed, 19 Mar 2008, Sam Mason <[EMAIL PROTECTED]> writes:
> ...
> char * str = cstring_of_text(src_text);
> ...
>
> I think I got my original inspiration for doing it this way around from
> the Caml language.
Also, used in Common Lisp as class accessors:
char *s = cstring_of(text);
text *t
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Brendan Jurd wrote:
> As discussed on -hackers, I'm trying to get rid of some redundant code
> by creating a widely u
As discussed on -hackers, I'm trying to get rid of some redundant code
by creating a widely useful set of functions to convert between text
and C string in the backend.
The new extern functions, declared in include/utils/builtins.h and
defined in backend/utils/adt/varlena.c, are:
char * text_cstr
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> So far, I've got the following functions doing the work:
> char * text_cstring(text *t)
> char * text_cstring_limit(text *t, int len)
> text * cstring_text(char *s)
> It wouldn't be difficult at this point to make those functions
> 'varlena' rather tha
On 9/22/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> On grounds of code-space savings I think it might be worth making
> these things be simple functions declared in builtins.h; that would
> also make it much easier to change their implementations.
I've noticed that this pattern isn't exclusive to th
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> The thing that's got me confused at the moment is what naming
> convention to use for the functions.
Well, almost any convention you like has some precedent somewhere in
the PG code, given all the contributors over the years. Almost the
only thing we a
On 9/22/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
> > I just noticed a couple of macros defined in src/include/tsearch/ts_utils.h:
>
> > #define TextPGetCString(t)
> > DatumGetCString(DirectFunctionCall1(textout, PointerGetDatum(t)))
> > #define CStringGet
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> I just noticed a couple of macros defined in src/include/tsearch/ts_utils.h:
> #define TextPGetCString(t)
> DatumGetCString(DirectFunctionCall1(textout, PointerGetDatum(t)))
> #define CStringGetTextP(c) DatumGetTextP(DirectFunctionCall1(textin,
> CStrin
Well, a couple of specific cases that I came across are
quote_identifier() in src/backend/utils/adt/quote.c, and
do_to_timestamp() in src/backend/utils/adt/formatting.c (line 3349).
I was getting a rough notion of how common the duplication was using
$ egrep -Rn -C 2 'memcpy.*VARDATA' src/backend
On 9/22/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
> The canonical way to do it is with
>
> DatumGetCString(DirectFunctionCall1(textout, t))
I just noticed a couple of macros defined in src/include/tsearch/ts_utils.h:
#define TextPGetCString(t)
DatumGetCString(DirectFunctionCall1(textout, Point
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> On 9/22/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
>> The canonical way to do it is with
>>
>> DatumGetCString(DirectFunctionCall1(textout, t))
>
> Ah, I see. Thanks.
>
> In that case, would it be helpful if I submitted a patch for the
> various cod
On 9/22/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
> The canonical way to do it is with
>
> DatumGetCString(DirectFunctionCall1(textout, t))
Ah, I see. Thanks.
In that case, would it be helpful if I submitted a patch for the
various code fragments that do this locally, updating them to use
Dat
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> Surely having the exact same four lines of code written out in dozens
> of places is a Bad Thing, but perhaps there is some reasoning behind
> this that I am missing?
The canonical way to do it is with
DatumGetCString(DirectFunctionCall1(textout, t))
23 matches
Mail list logo