Hi there,
I am compiling postgresql 7.1beta4. How would i change the default 8k
row limit?
--
Manny C. Cabido
e-mail:[EMAIL PROTECTED]
Tom Lane wrote:
m w [EMAIL PROTECTED] writes:
I think this exposes a bug in postgres where either
index or table scans (I'm not sure which just yet)
treat a zero differently than a non-zero in a varchar.
Embedded zeroes aren't supported in char/varchar/text fields,
and cannot be
--- Hannu Krosing [EMAIL PROTECTED] wrote:
Should we not examine "the _possible_ outputs of
every C-coded function
to make sure it produces a valid value of the
datatype" ;)
For me producing an invalid data for a datatype
seems very much like
a bug and it _should_ be reported.
No, I
Hannu Krosing [EMAIL PROTECTED] writes:
Is there no simple (i.e. cheap) way to disallow \0 alltogether for
these types then ?
perhaps just strip them out in textin() (or is it text_in()) ?
They *are* stripped out in textin(), by virtue of the fact that
textin expects to see a null-terminated
m w [EMAIL PROTECTED] writes:
Inconsistent behavior indicates that a different
matching algorithm is used if one uses an index
instead of a table scan. That scares me.
A seq scan and an index scan are inherently different algorithms,
so I don't see exactly how you think we can avoid this
Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
Is there no simple (i.e. cheap) way to disallow \0 alltogether for
these types then ?
perhaps just strip them out in textin() (or is it text_in()) ?
They *are* stripped out in textin(), by virtue of the fact that
textin expects
Hannu Krosing [EMAIL PROTECTED] writes:
Also I remember being told that bytea _can_ hold embedded \0, no ?
Yes. What has that got to do with text et al?
Possibly chr() should reject chr(0) ...
there is no function chr() at least in 7.0.2.
I think it used to be called ichar(), but then
m w [EMAIL PROTECTED] writes:
Here is the problem: Depending on whether there is an
index or not, 'like' behaves differently.
Please provide a complete, self-contained example with which
we can reproduce the problem.
regards, tom lane
--- Tom Lane [EMAIL PROTECTED] wrote:
m w [EMAIL PROTECTED] writes:
Here is the problem: Depending on whether there is
an
index or not, 'like' behaves differently.
Please provide a complete, self-contained example
with which
we can reproduce the problem.
I am trying to create a test
m w [EMAIL PROTECTED] writes:
I think this exposes a bug in postgres where either
index or table scans (I'm not sure which just yet)
treat a zero differently than a non-zero in a varchar.
Embedded zeroes aren't supported in char/varchar/text fields,
and cannot be supported in a portable
--- Zeugswetter Andreas SB
[EMAIL PROTECTED] wrote:
I am reposting this because I'm not sure it
actually
made it to the list.
It did make it to the list, but can you give
more
details whether or which of the
following you use:
--enable-locale ?
In 7.1 the row limit is not as big a deal because of
tuple toaster. I had a 7.0 database that needed the
row limit change, in 7.1 it does not seem too.
But if you want to chang it anyway, in config.h, look
for this line:
#define BLCKSZ 8192
It can be made as large as 32768.
--- Manuel
I am reposting this because I'm not sure it actually
made it to the list.
I have a function to transform text into a
pseudo-metaphone variable, take this example:
cddbsql=# select song, metatext(song) from cdsongs
where metatext(song) like metatext('born to run')
limit 3 ;
song |
I have a function to transform text into a
pseudo-metaphone variable, take this
example:
cddbsql=# select song, metatext(song) from cdsongs
where metatext(song) like
metatext('born to run') limit 3 ;
song | metatext
-+--
Born To Run | brntorn
Born To Run | brntorn
14 matches
Mail list logo
