"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> Well ... if somebody does want to change the representation of xml
> down the road, he's going to have to touch all the sites where the
> code converts to and from cstring anyway, right?
True.
> With that in mind, please find attached my followup patch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Apr 17, 2008 at 1:16 AM, Tom Lane wrote:
> "Brendan Jurd" writes:
>
> >> If we don't want to meddle with xmltype/bytea/VarChar at all, we'll
> >> have to revert those changes, and I'll have to seriously scale back
> >> the cleanup patch I w
Tom Lane wrote:
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
If we don't want to meddle with xmltype/bytea/VarChar at all, we'll
have to revert those changes, and I'll have to seriously scale back
the cleanup patch I was about to post.
Still not sure where we stand on the above.
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
>> If we don't want to meddle with xmltype/bytea/VarChar at all, we'll
>> have to revert those changes, and I'll have to seriously scale back
>> the cleanup patch I was about to post.
> Still not sure where we stand on the above. To cast, or not to cast?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Mar 29, 2008 at 5:40 AM, Brendan Jurd wrote:
> On 29/03/2008, Tom Lane wrote:
> > I intentionally didn't touch xml.c, nor anyplace that is not dealing
> > in text, even if it happens to be b
On 29/03/2008, Tom Lane <[EMAIL PROTECTED]> wrote:
> I intentionally didn't touch xml.c, nor anyplace that is not dealing
> in text, even if it happens to be binary-compatible with text.
>
Hmm, okay. My original submission did include a few such changes; for
example, in xml_in and xml_out_intern
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> On 26/03/2008, Tom Lane <[EMAIL PROTECTED]> wrote:
>> There are no textout/textin calls left, but I may have missed some
>> places that were doing it the hard way with direct palloc/memcpy
>> manipulations. It might be worth trolling all the VARDATA() r
On 26/03/2008, Tom Lane <[EMAIL PROTECTED]> wrote:
> There are no textout/textin calls left, but I may have missed some
> places that were doing it the hard way with direct palloc/memcpy
> manipulations. It might be worth trolling all the VARDATA() references
> to see if any more are easily re
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> 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.
Applied with revisions --- the functions were modified as per recent
discussion,
>
> 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
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> One of the questions in the original patch submission was whether it
> would be worth changing all those DirectFunctionCall(textin) and
> (textout) calls to use the new functions. Is it worthwhile avoiding
> the fmgr overhead?
I think that's worth doin
On 20/03/2008, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> I started to look at applying this patch and immediately decided that
> I didn't like these names --- it's exceeding un-obvious which direction
> of conversion any one of the functions performs. Seems like every time
> you wanted to call on
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
On Wed, Mar 19, 2008 at 12:51:35PM -0400, Tom Lane wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
> > char * text_cstring(const text *t)
>
> What do people think of text_to_cstring?
I tend to put things the other way around in my code, i.e:
char * cstring_of_text(const text *t)
mainly be
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> 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 i
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
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))
Hi hackers,
I've noticed that there is a lot of code, particularly in src/backend,
that goes through the motions of making a text datum into a cstring to
perform some work on it, and likewise for making a cstring into a text
datum.
Is there not a nice macro somewhere to handle this consistently?
38 matches
Mail list logo
