Quoting Tom Lane <[EMAIL PROTECTED]>:
> The JDBC support for over-the-wire access to large objects used to
> have some bugs, but AFAIK those are cleaned up in current sources
> (right Peter?)
Yes except for DatabaseMetaData.getTables() but thats not directly to do with
large objects.
As long a
> Yes, this was my point. We now have TOAST, but by not going the extra
> mile to enable storage of binary files, we really aren't taking full
> advantage of our new TOAST feature.
>
> I can see people saying, "Wow, you can store rows of unlimited length
> now. Let me store this jpeg. Oh, I ca
> This is a misunderstanding. You can still use the old-style large
> objects (in fact 7.1 has an improved implementation of them too),
> and there's always been support for either over-the-wire or
> server-filesystem read and write of large objects. In fact the former
> is the preferred way; th
what is the tentative date for 7.1 release?
what is the release date for replication?
sandeep
Joe Kislo <[EMAIL PROTECTED]> writes:
> ... this lack of BLOB support. I understand that the C
> API can read/write -files- off the server's filesystem and load them
> into the database. Unfortunately we would absolutely require true
> over-the-wire blob support through JDBC. AFAIK, even with t
Joe Kislo writes:
> First, I was evaluating Postgre for a medium scale application I will
I'm just wondering what this "Postgre" thing is you keep talking about...
;-)
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
> > What I think we _really_ need is a large object interface to TOAST data.
> > We already have a nice API, and even psql local large object handling.
> >
> > If I have a file that I want loaded in/out of a TOAST column, we really
> > should make a set of functions to do it, just like we do with
> What I think we _really_ need is a large object interface to TOAST data.
> We already have a nice API, and even psql local large object handling.
>
> If I have a file that I want loaded in/out of a TOAST column, we really
> should make a set of functions to do it, just like we do with large
> o
Joe Kislo wrote:
>Yes. There are certainly times when a transaction needs to be
> ABORTed. However, there are many reasons why the database should not
> abort a transaction if it does not need to. There is obviously no
> reason why a transaction needs to be aborted for syntax errors. There
On Thu, Nov 30, 2000 at 12:16:39PM -0800, Mikheev, Vadim wrote:
> Oracle & Interbase have savepoints. Hopefully PG will also have them in 7.2
A feature that I liked from using Faircom's Ctree (granted not an SQL based
DB or one with built in relations) was auto-save points. So, if something
fail
> > What's nice about PostgreSQL is that, while it hasn't always had
> > every SQL92 feature (like outer joins, etc.), it seems to have less
> > legacy, nonstandard stuff wired in. :-)
>
> Oh man, you have n idea. PostgreSQL is legacy headquarters. ;-)
Yes, yes, I know about *some* of them
Joel Burton writes:
> What's nice about PostgreSQL is that, while it hasn't always had
> every SQL92 feature (like outer joins, etc.), it seems to have less
> legacy, nonstandard stuff wired in. :-)
Oh man, you have n idea. PostgreSQL is legacy headquarters. ;-)
--
Peter Eisentraut
On 30 Nov 2000, at 11:58, Joe Kislo wrote:
> If you don't believe me, here's two fully SQL-92
> compliant databases, Oracle and interbase, which do not exhibit this
> behavior:
Ummm... havings lots of experience w/it, I can say many things
about Oracle, but "fully SQL-92 compliant" sure isn't
> > That is what transactions are for. If any errors occur, then the
> > transacction is aborted. You are supposed to use
> > transactions when you want either everything to occur
> > (the whole transaction), or nothing, if an error occurs.
>
> Yes. There are certainly times when a transa
>> How _much_ longer? (Sorry if it's a FAQ, in that case, I'd appreciate
>> a pointer/URL).
> Dunno, but I've been using 7.1devel for ~2 months, and so far,
> longer rows seem to work fine.
> More information on the TOAST project is at
> http://www.postgresql.org/projects/devel-toast.html
I t
On 30 Nov 2000, at 1:24, Igor V. Rafienko wrote:
> on Nov 29, 2000, 19:17, Joel Burton std::cout'ed:
>
> [snip]
>
> | > 5) BLOB Support.
> |
> | Keep in mind the pgsql 7.1 (about to go beta tomorrow, if I heard |
> right) will support much longer row sizes than 8k. Doesn't remove |
> the nee
on Nov 29, 2000, 19:17, Joel Burton std::cout'ed:
[snip]
| > 5) BLOB Support.
|
| Keep in mind the pgsql 7.1 (about to go beta tomorrow, if I heard
| right) will support much longer row sizes than 8k. Doesn't remove
| the needs for blobs for many of us, but fixed my problems.
How _much_ lon
[re: question #4, speed/vacuuming]
> Do
> people need to vaccume their databases hourly? Can you vaccume while
> a database is in use? Any discussion on this curious phenomenon would
> be appreciated. It still boggles me.
I vacuum twice a day, once in the dead of night, once around
lunch.
18 matches
Mail list logo
