Re: ALTER TABLE...ALTER COLUMN vs inheritance

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alex Hunsaker <badalex@gmail.com>
Cc: Bernd Helmle <mailings@oopsware.de>, pgsql-hackers@postgresql.org
Date: 2009-11-12T23:07:25Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Catalog NOT NULL constraints

Alex Hunsaker <badalex@gmail.com> writes:
> On Thu, Nov 12, 2009 at 13:55, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I'd go for the first of those, for sure. Testing attnotnull is
>> significantly cheaper than enforcing a generic constraint expression,
>> and NOT NULL is a sufficiently common case to be worth worrying about
>> optimizing it.

> When I looked at doing this, I thought about just using check
> constraints just for the book keeping and leaving attnotnull as it is.

Yeah, you could definitely attack it like that.  The code that fixes up
attnotnull would have to look for check constraints that look like "foo
NOT NULL" rather than something more instantly recognizable, but
presumably ALTER TABLE is not a performance-critical path.

			regards, tom lane