On Wed, Mar 05, 2008 at 07:38:21PM -0300, Alvaro Herrera wrote:
Magnus Hagander wrote:
Alvaro Herrera wrote:
I checked the Majordomo logs and there's nothing about those patches.
I do see one message with the Subject: pgsql: Clean up double negative,
per Tom Lane. line. A message held
Magnus Hagander wrote:
On Wed, Mar 05, 2008 at 07:38:21PM -0300, Alvaro Herrera wrote:
revision 1.23
date: 2008/03/05 19:42:11; author: alvherre; state: Exp; lines: +4 -4
Add support for dlopen on recent NetBSD/MIPS, per Rémi Zara.
19:42:11 I have one email going out to
Heikki Linnakangas wrote:
Heikki Linnakangas wrote:
Heikki Linnakangas wrote:
Attached is a patch that modifies CopyReadLineText so that it uses
memchr to speed up the scan. The nice thing about memchr is that we
can take advantage of any clever optimizations that might be in libc
or
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Andrew Dunstan wrote:
Heikki Linnakangas wrote:
Another update attached: It occurred to me that the memchr approach is
only safe for server encodings, where the non-first bytes of a
multi-byte character always have the hi-bit set.
We currently make the following assumption in the code:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Andrew Dunstan wrote:
We currently make the following assumption in the code:
* These four characters, and the CSV escape and quote characters, are
* assumed the same in frontend and backend encodings.
The four characters are the carriage
Tom Lane wrote:
BTW, I notice that the code allows CSV escape and quote characters that
have the high bit set (in single-byte server encodings that is). Is
this a good idea? It seems like such are extremely unlikely to be the
same in two different encodings. Maybe we should restrict to the
Heikki Linnakangas wrote:
Andrew Dunstan wrote:
Heikki Linnakangas wrote:
Another update attached: It occurred to me that the memchr approach is
only safe for server encodings, where the non-first bytes of a
multi-byte character always have the hi-bit set.
We currently make the
Andrew Dunstan wrote:
I'm still a bit worried about applying it unless it gets some adaptive
behaviour or something so that we don't cause any serious performance
regressions in some cases.
I'll try to come up with something. At the most conservative end, we
could fall back to the current
Heikki Linnakangas wrote:
Andrew Dunstan wrote:
I'm still a bit worried about applying it unless it gets some
adaptive behaviour or something so that we don't cause any serious
performance regressions in some cases.
I'll try to come up with something. At the most conservative end, we
Andrew Dunstan wrote:
Heikki Linnakangas wrote:
Andrew Dunstan wrote:
I'm still a bit worried about applying it unless it gets some
adaptive behaviour or something so that we don't cause any serious
performance regressions in some cases.
I'll try to come up with something. At the most
On Thu, 6 Mar 2008, Heikki Linnakangas wrote:
At the most conservative end, we could fall back to the current method
on the first escape, quote or backslash character.
I would just count the number of escaped/quote characters on each line,
and then at the end of the line switch modes between
snip
It seems much more restrictive than necessary, plus it does nothing
for the check-constraint case. My recollection of the previous
discussion about how to fix this was that we needed to add an inhcount
column to pg_constraint, and add entries for not-null constraints (at
least
Greg Smith wrote:
On Thu, 6 Mar 2008, Heikki Linnakangas wrote:
At the most conservative end, we could fall back to the current
method on the first escape, quote or backslash character.
I would just count the number of escaped/quote characters on each
line, and then at the end of the line
Edwin Groothuis wrote:
Is it possible to make it a WARNING instead of an ERROR? Right now I get:
No. All of the other types emit an ERROR if you're trying an out of
range value.
--
Euler Taveira de Oliveira
http://www.timbira.com/
--
Sent via pgsql-patches mailing list
On Thu, Mar 06, 2008 at 08:19:35PM -0300, Euler Taveira de Oliveira wrote:
Edwin Groothuis wrote:
Is it possible to make it a WARNING instead of an ERROR? Right now I get:
No. All of the other types emit an ERROR if you're trying an out of
range value.
Does that then mean that, because
Euler Taveira de Oliveira [EMAIL PROTECTED] writes:
Edwin Groothuis wrote:
Is it possible to make it a WARNING instead of an ERROR? Right now I get:
No. All of the other types emit an ERROR if you're trying an out of
range value.
I don't think that follows. A tsearch index is lossy
Tom Lane wrote:
I don't think that follows. A tsearch index is lossy anyway, so there's
no hard and fast reason why it should reject entries that it can't index
completely. I think it would be more useful to index whatever it can
(probably just the words in the first N bytes of the document)
Euler Taveira de Oliveira [EMAIL PROTECTED] writes:
The problem with this approach is how to select the part of the document
to index. How will you ensure you're not ignoring the more important
words of the document?
That's *always* a risk, anytime you do any sort of processing or
19 matches
Mail list logo
