On Tue, Mar 27, 2001 at 03:02:57PM +0930, Stephen Davies wrote:
> Yes, that is what I mean: every column in the affected rows had been
> changed to null;
>
> The description is:
>
> Table "request"
> Attribute | Type | Modifier
> -------------+----------+----------------------------------------
> id | integer | default nextval('reqid'::text)
> agency_id | integer |
> opportunity | text |
> start_date | date |
> end_date | date |
> focus | text |
> slots | smallint |
> filled | smallint |
> referred | smallint |
> date_recd | date | default date("timestamp"('now'::text))
> task | text |
> uflg | boolean | default 'f'
> Indices: redtx,
> reqkey,
> rfocx,
> rmemx,
> rsdtx,
> tskx
>
>
> On Tue, 27 Mar 2001 00:09:46 -0500, Tom Lane said:
> > Stephen Davies <scldad@sdc.com.au> writes:
> > > I have just had to restore a database from backup because the majority
> > > of records in one table had "magically" become null.
> >
> > There's no such thing as a null record in Postgres. What do you mean
> > exactly: were the records still present but their fields all read as
> > nulls?
> >
> > What is the declaration of the table?
> >
> > regards, tom lane
So you have nothing to prevent ...
UPDATE request
SET id = NULL, agency_id = NULL, opportunity = NULL,
start_date = NULL, end_date = NULL, focus = NULL,
slots = NULL, filled = NULL, referred = NULL, date_recd = NULL,
task = NULL, uflg = NULL;
... from succeeding. I'd suspect an errant query/update, perhaps tied
to one of the original values of one of your fields (say agency_id ??).
--
Eric G. Miller <egm2@jps.net>
