"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Here's a patch that fixes the send/recv functions to work like the
> manual says. It fixes the free/pfree typo as well.
Applied with a further fix: the patch caused xml_recv to call
parse_xml_decl with a non-null-terminated string, which could in
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Oh, I see what you mean. Yeah, the absolute paths need to be fixed :).
Easier to just remove the regression test altogether. Not every patch
requires permanent memorialization in a regression test.
regards, tom lane
Done by Teodor.
---
Heikki Linnakangas wrote:
> Teodor Sigaev wrote:
> >> I am getting confused with the patches and version I have lying around
> >> here... I think I'll have to wait for review of the patches I've posted
>
Heikki Linnakangas wrote:
> Alvaro Herrera wrote:
>> Heikki Linnakangas wrote:
>>
>>> + -- Basic test
>>> + COPY xmltest TO
>>> '/home/hlinnaka/pg_sandbox/pgsql.cvshead/src/test/regress/results/xmltest.data'
>>> WITH BINARY;
>>> + TRUNCATE xmltest;
>>> + COPY xmltest FROM
>>> '/home/hlinnaka/pg_
Alvaro Herrera wrote:
> Heikki Linnakangas wrote:
>
>> + -- Basic test
>> + COPY xmltest TO
>> '/home/hlinnaka/pg_sandbox/pgsql.cvshead/src/test/regress/results/xmltest.data'
>> WITH BINARY;
>> + TRUNCATE xmltest;
>> + COPY xmltest FROM
>> '/home/hlinnaka/pg_sandbox/pgsql.cvshead/src/test/regre
Heikki Linnakangas wrote:
> + -- Basic test
> + COPY xmltest TO
> '/home/hlinnaka/pg_sandbox/pgsql.cvshead/src/test/regress/results/xmltest.data'
> WITH BINARY;
> + TRUNCATE xmltest;
> + COPY xmltest FROM
> '/home/hlinnaka/pg_sandbox/pgsql.cvshead/src/test/regress/results/xmltest.data'
> WITH
Heikki Linnakangas wrote:
> Heikki Linnakangas wrote:
>> BTW, the encoding of the XML datatype looks pretty funky. xml_recv first
>> reads the xml string with pq_getmsgtext, which applies a client->server
>> conversion. Then the xml declaration is parsed, extracting the encoding
>> attribute. Then
Teodor Sigaev wrote:
>> I am getting confused with the patches and version I have lying around
>> here... I think I'll have to wait for review of the patches I've posted
>> this far before I continue hacking.
> Sorry for delay - I was busy by another. All your patches are committed
> with very smal
I am getting confused with the patches and version I have lying around
here... I think I'll have to wait for review of the patches I've posted
this far before I continue hacking.
Sorry for delay - I was busy by another. All your patches are committed with
very small changes.
--
Teodor Sigaev
BTW, Teodor, are you intending to review/apply Heikki's tsearch fixes,
or do you want someone else to do it?
I'll do it.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
---
Heikki Linnakangas wrote:
> BTW, the encoding of the XML datatype looks pretty funky. xml_recv first
> reads the xml string with pq_getmsgtext, which applies a client->server
> conversion. Then the xml declaration is parsed, extracting the encoding
> attribute. Then the string is converted again fr
Tom Lane wrote:
> Any portion of a binary value that is considered textual should be
> converted to and from client encoding --- cf textsend/textrecv.
> This should be pretty trivial to fix, just call a different support
> routine.
You do need to adjust length and position fields in the structs as
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> I started to write a patch for that, as I realized that we're
> transferring the strings in a tsvector/tsquery in server encoding.
> That's not good, right? A dump created with COPY ... BINARY wouldn't be
> portable across clusters with different e
Teodor Sigaev wrote:
> Heikki Linnakangas wrote:
>> In any case, I think we need to calculate the CRC/hash in tsqueryrecv,
>> instead of trusting the client.
> Agreed.
I started to write a patch for that, as I realized that we're
transferring the strings in a tsvector/tsquery in server encoding.
T
Heikki Linnakangas wrote:
Teodor Sigaev wrote:
Ok. Probably easiest to do that by changing the palloc to palloc0 in
parse_tsquery.
and change sizeof to sizeof(QueryItem)
Do you mean the sizeofs in the memcpys in parse_tsquery? You can't
Oops, I meant pallocs in push* function. palloc0 in
Teodor Sigaev wrote:
>> Ok. Probably easiest to do that by changing the palloc to palloc0 in
>> parse_tsquery.
>
> and change sizeof to sizeof(QueryItem)
Do you mean the sizeofs in the memcpys in parse_tsquery? You can't
change them. The source structs are allocated in
pushOperand/pushOperator, u
Ok. Probably easiest to do that by changing the palloc to palloc0 in
parse_tsquery.
and change sizeof to sizeof(QueryItem)
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
Teodor Sigaev wrote:
> Heikki, I see some strange changes in your patch, not related to tsearch
> at all:
> contrib/pageinspect/pageinspect.sql.in
> contrib/pageinspect/rawpage.c
Oh, sorry about that. Just ignore them, they are some quick&dirty
debugging functions I had in the same source tree.
>
I fixed this by making the left-field a uint32. There's no reason to
arbitrarily limit it to 16-bits, and it won't increase the disk/memory
footprint either now that QueryOperator and QueryOperand are separate
structs.
...
I added check_stack_depth() call to all recursive functions I found.
Some
Heikki, I see some strange changes in your patch, not related to tsearch at all:
contrib/pageinspect/pageinspect.sql.in
contrib/pageinspect/rawpage.c
The usage of the QueryItem struct was very confusing. It was used for
both operators and operands. For operators, "val" was a single character
cas
I wrote:
> I have a few more things in mind I'm planning to look into:
>
> - I'm not convinced that there's enough sanity checking in the input
> functions. I think you can send queries into the server using the binary
> protocol that you couldn't produce otherwise. For example, queries with
> mul
21 matches
Mail list logo
