On Sun, Feb 8, 2009 at 11:51 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> Tom Lane wrote:
>>> The attached patch (which lacks doc changes or regression
>>> tests as yet) does that, and also adds the inverse SET WITH OIDS
>>> operation to do what you'd expect, ie, add an OID column if it isn't
>>> there already.
>
>> Why would we add an operation to implement a deprecated feature?
>
> Well, it was always intended to be that way:
> http://archives.postgresql.org/pgsql-patches/2002-12/msg00071.php
>
> The originally submitted patch didn't work very well
> http://archives.postgresql.org/pgsql-patches/2003-01/msg00011.php
> and what we ended up doing was applying just the SET WITHOUT OIDS half
> of it, but my feeling always was that that was for lack of round tuits
> rather than that it was a good place to be. Given the implementation
> at the time it would've taken a lot of extra code to do SET WITH OIDS,
> so nobody did get around to it. But subsequent changes in the ALTER
> code have made it possible to piggyback on ALTER ADD COLUMN easily ---
> which is what this patch is trying to demonstrate.
>
> Now, if you want to argue that we should get rid of SET WITHOUT OIDS
> altogether, I'm not sure I could dispute it. But if we have the ability
> to do that ISTM we should offer the reverse too.
+1. I really hate it (in any application, not just PostgreSQL) when
there's an option to add something but not delete it, delete it but
not put it back, etc. Personally, *I* would not have spent the time
to implement SET WITH OIDS, but since we now have the patch, I'm 100%
in favor of applying it. Most likely, very few people will use it,
but it doesn't cost us anything either, so I'm unclear why we would
tell Tom to go back and rip that functionality back out of his patch.
Sounds like bikeshedding to me.
...Robert
