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 →
-
Catalog NOT NULL constraints
- e056c557aef4 16.0 landed
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