Shachar Shemesh [EMAIL PROTECTED] writes:
Tom Lane wrote:
I seem to recall also that there are machines that
treat the exponent as power-of-16 not power-of-2.
I'm pretty sure I don't understand this. Maybe I misunderstood the
format, but wouldn't that actually lose you precision with, at
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
We should only be able to get out of step from the %_ case, I believe,
so we should only need to do the first-byte test in that case (which is
in a different code path from the normal _ case. Does that seem right?
At least
Dear Developers,
Hi, I am Tasneem Memon doing MS Computer Science. I am working on my thesis
these days, for which I have defined some operators theoritically as well as
their algorithms, and intend to implement them in PostgreSQL. These
operators(NEAR, NOT NEAR) are binary and work with
Tasneem Memon [EMAIL PROTECTED] writes:
Hi, I am Tasneem Memon doing MS Computer Science. I am working on my thesis=
these days, for which I have defined some operators theoritically as well =
as their algorithms, and intend to implement them in PostgreSQL. These oper=
ators(NEAR, NOT NEAR)
Andrew Dunstan [EMAIL PROTECTED] writes:
OK, Here is a patch that I am fairly confident does what's been
discussed, as summarised by Tom.
! #define CHAREQ(p1, p2) (*p1 == *p2)
...
+ #define IsFirstByte(c) ((*c 0xC0) != 0x80)
These macros are bugs waiting to happen. Please parenthesize
Tom Lane wrote:
I'm not sure I believe the new coding for %-matching at all, and I
certainly don't like the 100% lack of comments explaining why the
different cases are necessary and just how they differ. In particular,
once we've advanced more than one character, why does it still matter
On 05/21/2007 04:52:35 PM, Tom Lane wrote:
Karl O. Pinc [EMAIL PROTECTED] writes:
On 05/19/2007 12:41:47 PM, Tom Lane wrote:
There's been previous discussion of allowing BEFORE INSERT triggers
on views, so long as the triggers always return NULL to suppress
the actual insertion attempt (ie,
Am I correct to assume that the backend does not implement cursor
declaration from prepared statements? If so, is there a reason for this?
That is something like this:
PREPARE p AS
SELECT * FROM foo;
DECLARE c CURSOR for p;
AFAIRC the standard says this group of statements are perfectly
Michael Meskes [EMAIL PROTECTED] writes:
PREPARE p AS
SELECT * FROM foo;
DECLARE c CURSOR for p;
AFAIRC the standard says this group of statements are perfectly legal
I'd be interested to see where you draw that conclusion, since
(a) PREPARE statements of that form are not in the
While looking at Jaime's last temp_tablespaces GUC patch, i've got some
concerns about it's current implementation:
1)
The code claims that OIDs of temp tablespaces couldn't be cached, therefore
it is parsing and
re-reading the GUCs in GetTempTablespace() with SplitIdentifierNames() over
and
Bernd Helmle escribió:
It's possible that someone could drop a temporary tablespace between
subsequent usage of GetTempTablespace() when they are empty. This leads to
strange NOTICEs like
NOTICE: could not create temporary file
pg_tblspc/16387/pgsql_tmp/pgsql_tmp19942.0
during query
Tom Lane wrote:
There should somewhere be a block comment explaining all the reasoning
we've so painfully gone through about why the three cases (SB, MB, UTF8)
are needed and how they must differ.
I'm working on a detailed description/rationale.
However, I have
On 5/24/07, Bernd Helmle [EMAIL PROTECTED] wrote:
While looking at Jaime's last temp_tablespaces GUC patch, i've got some
concerns about it's current implementation:
the original patch is from Albert Cervera =)
1)
The code claims that OIDs of temp tablespaces couldn't be cached, therefore
On 5/24/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
Bernd Helmle escribió:
It's possible that someone could drop a temporary tablespace between
subsequent usage of GetTempTablespace() when they are empty. This leads to
strange NOTICEs like
NOTICE: could not create temporary file
Jaime Casanova [EMAIL PROTECTED] writes:
On 5/24/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
What happens if you create a cursor that stores something (sort
intermediate results?) in a temp tablespace, FETCH some from it, then
someone else drops the tablespace and FETCH some more?
you can't
Andrew Dunstan [EMAIL PROTECTED] writes:
However, I have just about convinced myself that we don't need
IsFirstByte for matching _ for UTF8, either preceded by % or not, as
it should always be true. Can anyone come up with a counter example?
You have to be on a first byte before you can
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
However, I have just about convinced myself that we don't need
IsFirstByte for matching _ for UTF8, either preceded by % or not, as
it should always be true. Can anyone come up with a counter example?
You have to be on a
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
You have to be on a first byte before you can meaningfully apply
NextChar, and you have to use NextChar or else you don't count
characters correctly (eg __ must match 2 chars not 2 bytes).
Yes, I agree completely. However it looks to
Chaps:
I am currently after the block size being used by major rdbm's and how
do they take advantage of it.
(ie, postgresql does interacts basically in two ways, by WAL'ing, and
by the update activity, block size 8192)
While I am googling this, hints will be apreciated.
Thanks in advance,
--
I wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Yes, I agree completely. However it looks to me like IsFirstByte will in
fact always be true when we get to call NextChar for matching _ for UTF8.
If that's true, the patch is failing to achieve its goal of treating %
bytewise ...
OK, I
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
You have to be on a first byte before you can meaningfully apply
NextChar, and you have to use NextChar or else you don't count
characters correctly (eg __ must match 2 chars not 2 bytes).
Yes, I
Tom Lane wrote:
OK, I studied it a bit more and now see what you're driving at: in this
form of the patch, we treat % bytewise unless it is followed by _, in
which case we treat it char-wise. That seems a good tradeoff,
considering that such a pattern is probably pretty uncommon --- we
should
On Thu, May 24, 2007 at 11:20:51PM -0400, Tom Lane wrote:
I wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Yes, I agree completely. However it looks to me like IsFirstByte will in
fact always be true when we get to call NextChar for matching _ for UTF8.
If that's true, the patch is
Hi,
I was walking through GIN am source code these days, and found that it has
only posting lists but no positions related those.
The reason I was doing that is, to try to implement n-gram text search index
on GIN for myself. As you know Japanese is not like English or other
European languages.
24 matches
Mail list logo
