From: Ron Peterson <rpeterso@mtholyoke.edu>
Date: Wed, 8 Jan 2003 13:13:03 -0500
To: pgsql-sql@postgresql.org
Subject: Re: insert rule doesn't see id field
Message-ID: <20030108181303.GA23456@mtholyoke.edu>
Mail-Followup-To: pgsql-sql@postgresql.org
References: <20030107145422.GE12245@mtholyoke.edu>
	<13558.1041955268@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <13558.1041955268@sss.pgh.pa.us>
User-Agent: Mutt/1.3.28i
Organization: Mount Holyoke College

On Tue, Jan 07, 2003 at 11:01:08AM -0500, Tom Lane wrote:

> > I thought that the idea behind noup was to protect single columns from
> > update.  However, when I apply the noup trigger as above, I can't
> > update /any/ column.  Is this the intended behaviour?
> 
> Idly looking at the source code for contrib/noupdate/noup.c, I don't
> believe that it has ever worked as advertised: it seems to reject any
> non-null value for the target column, independently of whether the
> value is the same as before (which is what I'd have thought it should
> do).
> 
> Is anyone interested in fixing it?  Or should we just remove it?
> If it's been there since 6.4 and you're the first person to try to use
> it, as seems to be the case, then I'd have to say that it's a waste of
> space in the distribution.

I'm going to see if I can create this function.  The issue I face is
that I'm allowing certain clients to access parts of a PostgreSQL
database on MS Access via ODBC.  This means I can't really control how
people may try to edit the data.  Well, I could, by using MS Access
security features, but I'd rather do what I can on the back end.

If someone changes an ID field, then as long as foreign key contraints
on other related tables are set to cascade or whatever, that won't be
a problem.  But what if someone updates an ID field to something
higher than my current sequence?  Then when the sequence hits that ID,
it will crap out.  Maybe just try again, but what if that happened to
a bunch of records?  Could be a pain.

So that's the problem I'd like to prevent, for which I think this
function would be useful.  So I'll hack at it and see what I come up
with.  Might not happen immediately, though..

-- 
Ron Peterson                          -o)
Network & Systems Manager             /\\
Mount Holyoke College                _\_v
http://www.mtholyoke.edu/~rpeterso   ----