GeoServer will not write in my PostgreSQL update view

Following on from this earlier question I'm on PostgreSQL 8.4 and am having trouble with updatable views.

I have a view:

CREATE VIEW filedata_view
AS SELECT num, id, ST_TRANSFORM(the_geom,900913) AS the_geom
FROM filedata

And want to update it from my application throw Geoserver. But get a error:

<ServiceExceptionReport version="1.2.0" xmlns="" xmlns:xsi="" xsi:schemaLocation="">
 <ServiceException> {}filedata_view is read-only    </ServiceException>

So views in PostgresSql are not updatable. I need create a rule or trigger to update the view.

I tried this:

ON UPDATE TO filedata_view DO INSTEAD  UPDATE filedata SET the_geom=ST_TRANSFORM(NEW.the_geom,70066)
WHERE num=NEW.num

but it didn't help, I'm still getting the same error.

Where is my mistake?

First, I couldn't agree more with Frank. Use 9.1, and a table trigger. However, it's possible that neither that nor a view will solve your problem.

Try doing a manual UPDATE on your view from psql. If that works, and if you connect using the same user ID with opengeospatial, then I'd say the issue could be opengeospatial being too clever for its own good and "knowing" that views can't be updated. Either that, or it's trying an INSERT and you haven't added a matching INSERT rule on your view.

The message "filedata_view is read-only" isn't a message PostgreSQL may produce. I'm wondering if opengeospatial is using JDBC metadata (assuming it's Java) or INFORMATION_SCHEMA or similar to query the schema, is determining that filedata_view is a view, and is concluding that it therefore can't update it.

If it were a message from PostgreSQL it would instead say:

# UPDATE customer_v SET customer_number = 1234;
ERROR:  cannot update view "the_view"
HINT:  You need an unconditional ON UPDATE DO INSTEAD rule or an INSTEAD OF UPDATE trigger.

It might be informative to enable log_statement = 'all' in postgresql.conf and reload postgresql. Re-test, then look in the logs see what exactly opengeospatial is doing.

If it turns out it's detecting a view, you might be able to work around the problem with an ON SELECT rule added to an empty table. The table will work just like a view, but GeoServer won't be able to tell it is a view and might agree to write to it.