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:
>
> 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 thi
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 t
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
> tex
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
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-termin
--- 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 reporte
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 ca
Embedded zeroes aren't supported in
> char/varchar/text fields,
> and cannot be supported in a portable fashion, since
> these datatypes
> rely on functions like strcoll() that don't allow
> embedded nulls in
> strings. It wouldn't surprise me too much if there
> are inconsistent
> behaviors bet
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 f
--- 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 c
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
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 Cabido
13 matches
Mail list logo
