Re: [INTERFACES] Problems with postgres V6.5.3 large objects
От | Douglas Thomson |
---|---|
Тема | Re: [INTERFACES] Problems with postgres V6.5.3 large objects |
Дата | |
Msg-id | 199912060935.UAA28036@mugca.cc.monash.edu.au обсуждение исходный текст |
Ответ на | Re: [INTERFACES] Problems with postgres V6.5.3 large objects (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [INTERFACES] Problems with postgres V6.5.3 large objects
|
Список | pgsql-interfaces |
> Most of the developers have not wanted to put much effort into large > objects, since where we really want to go is to eliminate tuple size > restrictions; once that happens large objects will be much less > necessary. I am curious about the planned interface once tuple size restrictions are eliminated. I am using large objects, and want to make my application port as painlessly as possible. If *all* that happens is that tuple size and SQL command length limits are eliminated, then presumably I will just use a TEXT attribute and do a normal INSERT to store my large object? But will that mean that I have to go right through my large objects and escape all the nasty binary characters (such as single quotes) that are illegal in an SQL string constant? If there is some other list where this discussion is accessible then please direct me! Doug. P.S. Did anyone ever comment about whether multi-table joins took advantage of individual table indexes on the joining attributes, or whether the join had to read in all the table data and sort it anyway? There was some trouble with duplicated postings at the time, and I may have missed something while I was purging the messages I had already read...
В списке pgsql-interfaces по дате отправления: