9k limit?

Justin Long wrote:

It appears that there is a 9k (8,991) limit on queries ... I have text files
that need to go in TEXT fields that are much longer than this. Does anyone
have any suggestions as to how to add them to the database? Has anyone else
encountered this problem?

Database records may not exceed 8k so increasing the query limit isn't
going to help you much (although I still think it should be increased).

There arn't many good options. You could use large objects (except that
their implementation sucks). Or you could break up the object. Something
like..
CREATE TABLE textfile (t text);
CREATE TABLE extrabits (ord int4, textfile oid);

If it fits into 8k you just use the text file class. If it spills over
you start having to populate the extrabits with an order by field ord.

Then you would SELECT textfile from extrabits order by ord where
textfile = 'the-oid-of-text-file-you-are-looking-for'; and join them all
back together

Really ugly I know. I hope these arbitrary limits are removed sometime
soon.

On Fri, 23 Apr 1999, Chris Bitmead wrote:

Justin Long wrote:

It appears that there is a 9k (8,991) limit on queries ... I have text files
that need to go in TEXT fields that are much longer than this. Does anyone
have any suggestions as to how to add them to the database? Has anyone else
encountered this problem?

Database records may not exceed 8k so increasing the query limit isn't
going to help you much (although I still think it should be increased).

There arn't many good options. You could use large objects (except that
their implementation sucks). Or you could break up the object. Something
like..
CREATE TABLE textfile (t text);
CREATE TABLE extrabits (ord int4, textfile oid);

If it fits into 8k you just use the text file class. If it spills over
you start having to populate the extrabits with an order by field ord.

Then you would SELECT textfile from extrabits order by ord where
textfile = 'the-oid-of-text-file-you-are-looking-for'; and join them all
back together

Really ugly I know. I hope these arbitrary limits are removed sometime
soon.

Another solution (although not particularly platform-independent) is to
store a path name in the database, and have your app open the file
pointed to thusly, read it, and display/ manipulate it however you want.

This is perhaps even more ugly than Chris's solution :)

You could even store just a file offset, and then you might only need one
text file to store all your text. No forget that. You would have too many
problems updating file offsets to make it worthwhile.

Simon.

--
"The real reason Heisenberg and Schrodinger didn't get along is because,
unknown to many historians, Heisenberg had a dog."

Simon Drabble Somewhere in cyberspace

On Thu, 22 Apr 1999, Justin Long wrote:

// It appears that there is a 9k (8,991) limit on queries ... I have
// text files that need to go in TEXT fields that are much longer than
// this. Does anyone have any suggestions as to how to add them to the
// database? Has anyone else encountered this problem?

When I do something like this, I do it in two tables where the
large data is referenced from the other table. For instance, a logging
system I designed for work uses a table called ``events'' that stores
timestamps and other generic event information, then another called
``messages'' that stores the actual textual data. The source of this data
is any random application and some people make *very* verbose event
entries. The way I handle this is to start a transaction, store all of
the event data, then break the message data into 3000 byte chunks, base64
encode it, then store each chunk referencing the id generated from the
event id sequence with an incrementing part number each time. This lets
me store an amount of data on a single message limited only by disk space.
It also means that people using it may start to send movies back as error
messages and all will be well (though it'll be a little painful getting it
into the database).

--
Principal Member Technical Staff, beyond.com The world is watching America,
pub 1024/3CAE01D5 1994/11/03 Dustin Sallings <dustin@spy.net>
| Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE
L______________________________________________ and America is watching TV. __

If I have a UNIQUE or PRIMARY KEY clause on my class, does that create a
btree or hash index?

I guess if I have a UNIQUE constraint or PRIMARY KEY at class creation,
I don't have to create an index explicitely via CREATE INDEX ?

If I want to have an index on oid, which will obviously be unique
anyway, is it more efficient to have or not to have the UNIQUE option on
CREATE INDEX ?

Does CREATE INDEX properly support the * notation ?

Like if I go CREATE INDEX on foobar*, does that index foobar and all its
subclasses?

If I have a UNIQUE or PRIMARY KEY clause on my class, does that create a
btree or hash index?

btree

I guess if I have a UNIQUE constraint or PRIMARY KEY at class creation,
I don't have to create an index explicitely via CREATE INDEX ?

correct

-DEJ

If I want to have an index on oid, which will obviously be unique
anyway, is it more efficient to have or not to have the UNIQUE option on
CREATE INDEX ?

Good question my thought would be not to have the Unique; then the Indexing
code doesn't have to check for duplicates when inserting new values.
-DEJ