Gregory Stark wrote:
>"Abhijit Menon-Sen" <[EMAIL PROTECTED]> writes:
>>> Interleaved retrieval using multiple portals is not what most
>>> libraries support, I'd guess.
>> My code did support that mode of operation in theory, but in practice
>> in the few situations where I have needed to use som
Am I correct in the assumption that even though the network protocol
specifically allows individual columns of a copy command to be
binary or text format, the current COPY command in 8.3 doesn't
support specifying that?
Am I missing something in the network protocol which allows me
to specify it r
"Stephen R. van den Berg" <[EMAIL PROTECTED]> writes:
> Am I correct in the assumption that even though the network protocol
> specifically allows individual columns of a copy command to be
> binary or text format, the current COPY command in 8.3 doesn't
> support specifying that?
Yeah, the protoc
"David E. Wheeler" <[EMAIL PROTECTED]> writes:
> When I deleted any of the others, I got errors like this:
> psql:sql/citext.sql:865: ERROR: function length(citext) is not unique
> LINE 1: SELECT is( length( name ), length(name::text), 'length("' ||...
> ^
> HINT: Could not c
"David E. Wheeler" <[EMAIL PROTECTED]> writes:
> On Jul 12, 2008, at 12:17, Tom Lane wrote:
>> * You should provide binary I/O (send/receive) functions, if you want
>> this to be an industrial-strength module. It's easy since you can
>> piggyback on text's.
> I'm confused. Is that not what the ci
"David E. Wheeler" <[EMAIL PROTECTED]> writes:
> On Jul 12, 2008, at 14:57, Tom Lane wrote:
>> Sadly, I think you have to give up
>> attempts to check the interesting multibyte cases and confine yourself
>> to tests using ASCII strings.
> Grr. Kind of defeats the purpose. Is there no infrastructur
Updated: http://www.sigaev.ru/misc/fast_insert_gin-0.9.gz
need more review of fast_insert yet? It looked like a number of people
commented on it already.
I still havn't clearness of acceptability for suggested aminsertcleanup
calling.
--
Teodor Sigaev E
On Jul 13, 2008, at 10:16, Tom Lane wrote:
Hmm. I think what that actually means is that the cast from citext to
bpchar should be AS ASSIGNMENT rather than IMPLICIT. What is
happening
is that the system can't figure out whether to use length(text) or
length(bpchar) when presented with a cit
On Jul 13, 2008, at 10:19, Tom Lane wrote:
"David E. Wheeler" <[EMAIL PROTECTED]> writes:
On Jul 12, 2008, at 12:17, Tom Lane wrote:
* You should provide binary I/O (send/receive) functions, if you
want
this to be an industrial-strength module. It's easy since you can
piggyback on text's.
On Jul 13, 2008, at 10:19, Tom Lane wrote:
I'm confused. Is that not what the citextin and citextout functions
are?
No, those are text I/O. You need analogues of textsend and textrecv
too.
Should those return bytea and citext, respectively? IOW, are these
right?
CREATE OR REPLACE FUNCT
On Jul 13, 2008, at 16:06, David E. Wheeler wrote:
Should those return bytea and citext, respectively? IOW, are these
right?
CREATE OR REPLACE FUNCTION citextrecv(bytea)
RETURNS citext
AS 'textrecv'
LANGUAGE 'internal' IMMUTABLE STRICT;
CREATE OR REPLACE FUNCTION citextsend(citext)
RETURNS b
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= <[EMAIL PROTECTED]> writes:
> OK, here's the (hopefully final) version of the typanalyze function for
> tsvectors. It applies to HEAD and passes regression tests.
> I now plan to move towards a selectivity function that'll use the
> gathered statistics.
Applied
"David E. Wheeler" <[EMAIL PROTECTED]> writes:
> To judge by the User-Defined Types docs, I was close. :-) I just
> changed the argument to citextrecv to "internal".
Right. The APIs for send and recv aren't inverses. (Oh, the sins
we'll commit in the name of performance ...)
(taking the discussions to -hackers)
On Sat, Jul 12, 2008 at 11:02 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>
>
> (2) It achieves speedup of VACUUM by pushing work onto subsequent
> regular accesses of the page, which is exactly the wrong thing.
> Worse, once you count the disk writes those accesse
Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= <[EMAIL PROTECTED]> writes:
> > OK, here's the (hopefully final) version of the typanalyze function for
> > tsvectors. It applies to HEAD and passes regression tests.
>
> > I now plan to move towards a selectivity function that'll use the
> > ga
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Should we have a CHECK_FOR_INTERRUPTS() call in the inner loop of
> compute_tsvector_stats?
Isn't the vacuum_delay_point() good enough?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Should we have a CHECK_FOR_INTERRUPTS() call in the inner loop of
> > compute_tsvector_stats?
>
> Isn't the vacuum_delay_point() good enough?
But that's in the outer loop ... I mean here:
Index: src/backend/tsearch/ts_typanalyze.c
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Isn't the vacuum_delay_point() good enough?
> But that's in the outer loop ... I mean here:
You'd need one heckuva lot of lexemes in a tsvector to make that
important. Do we have CHECK_FOR_INTERRUPTS() in any other loops
over tsvect
On Jul 13, 2008, at 10:19, Tom Lane wrote:
You might try running the
opr_sanity regression test on this module to see if it finds any
other silliness. (Procedure: insert the citext definition script
into the serial_schedule list just ahead of opr_sanity, run tests,
make sure you understand the
On Jul 13, 2008, at 10:31, Tom Lane wrote:
Grr. Kind of defeats the purpose. Is there no infrastructure for
testing multibyte functionality?
There's some stuff under src/test/locale and src/test/mb, though it
doesn't get exercised regularly. The contrib tests are a particularly
bad place for
20 matches
Mail list logo
