Re: [HACKERS] pg_dump/restore to convert BLOBs to LZTEXT (optional!)

From: Philip Warner <pjw(at)rhyme(dot)com(dot)au>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org, pgsql-general(at)postgreSQL(dot)org
Subject: Re: [HACKERS] pg_dump/restore to convert BLOBs to LZTEXT (optional!)
Date: 2000-08-04 01:29:28
Message-ID: 3.0.5.32.20000804112928.026df4f0@mail.rhyme.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

At 21:10 3/08/00 -0400, Tom Lane wrote:
>As well as break the semantics: if you have a multiply-referenced BLOB
>then you can update it through any reference and the changes are visible
>through all the references. Not so after you convert the data into
>non-BLOB values.

That's what I meant. People *shouldn't* expect BLOB fields to be updated in
more than one table, but the implementation currently allow it (since BLOBs
are not implemented as fields).

>I don't see that pg_dump can help meaningfully,
>and I'd just as soon resist feature bloat in pg_dump.

Fine. Thinking about it, even *if* it was implemented as a utility, I
suspect (for the reasons you outlined), conversion would be a multi-step
process. And a more useful utility would be one that converted an existing
database, rather than trying to everything in the 'restore'...

Forget I even mentioned it.

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.C.N. 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/

In response to

Browse pgsql-general by date

  From Date Subject
Next Message database 2000-08-04 03:13:38 Recursive SQL
Previous Message Tom Lane 2000-08-04 01:10:53 Re: [HACKERS] pg_dump/restore to convert BLOBs to LZTEXT (optional!)

Browse pgsql-hackers by date

  From Date Subject
Next Message Roland Roberts 2000-08-04 01:36:49 RH 6.1, PostgreSQL 7.0.2, ipcclean madness
Previous Message Tom Lane 2000-08-04 01:25:27 Re: MAC.C (still?)