From: | Greg Stark <greg(dot)stark(at)enterprisedb(dot)com> |
---|---|
To: | David Fetter <david(at)fetter(dot)org> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: WIP: fix SET WITHOUT OIDS, add SET WITH OIDS |
Date: | 2009-02-09 00:00:08 |
Message-ID: | 9941FE8D-2841-4AA0-9420-73BEEEC705B3@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I don't understand what's wrong with the existing setup where DROP
OIDS is a free operation. And the space is cleaned up later when the
tuple is next written.
It seems exactly equivalent to how we handle DROP COLUMN where the
natt field of the tuple disagrees with the tuple descriptor and any
additional columns are implicitly null.
--
Greg
On 8 Feb 2009, at 23:12, David Fetter <david(at)fetter(dot)org> wrote:
> On Sun, Feb 08, 2009 at 11:51:22AM -0500, Tom Lane wrote:
>>
>> Now, if you want to argue that we should get rid of SET WITHOUT OIDS
>> altogether,
>
> +1 for removing it altogether. Row OIDs are and ugly wart :P
>
> Cheers,
> David.
> --
> David Fetter <david(at)fetter(dot)org> http://fetter.org/
> Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
> Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
>
> Remember to vote!
> Consider donating to Postgres: http://www.postgresql.org/about/donate
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
From | Date | Subject | |
---|---|---|---|
Next Message | Mihai Criveti | 2009-02-09 01:24:19 | 64 bit PostgreSQL 8.3.6 build on AIX 5300-09-02-0849 with IBM XL C/C++ 10.1.0.1 - initdb fails (could not dump unrecognized node type: 650) |
Previous Message | David Fetter | 2009-02-08 23:12:18 | Re: WIP: fix SET WITHOUT OIDS, add SET WITH OIDS |