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. It
-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
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?
I dunno.
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. To
-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 was about to
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
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() references
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_internal I
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, and I
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 in
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 because
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 one,
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 doing just
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
14 matches
Mail list logo