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 something like
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
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 protocol is a
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 choose a
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 citextin and
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 infrastructure for
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
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
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
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
=?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 with
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 accesses will
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
gathered
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 tsvector
18 matches
Mail list logo
