--On 16. Juni 2010 14:31:00 +0200 Bernd Helmle maili...@oopsware.de wrote:
There are some spelling and grammar errors in comments that I can help
fix if you want the help.
You're welcome. I have pushed my branch to my git repos as well, if you
like to start from there:
On Wed, Jun 16, 2010 at 5:31 AM, Bernd Helmle maili...@oopsware.de wrote:
--On 15. Juni 2010 20:51:21 -0700 Selena Deckelmann selenama...@gmail.com
wrote:
Confirmed that this tests fine against commit id
0dca7d2f70872a242d4430c4c3aa01ba8dbd4a8c
I also wrote a little test script and
--On 15. Juni 2010 20:51:21 -0700 Selena Deckelmann selenama...@gmail.com
wrote:
Confirmed that this tests fine against commit id
0dca7d2f70872a242d4430c4c3aa01ba8dbd4a8c
I also wrote a little test script and verified that it throws an error
when I try to remove a constraint from the
On Wed, May 26, 2010 at 2:37 PM, Bernd Helmle maili...@oopsware.de wrote:
Lost it a little from my radar, but here's is a first shot on this issue
now. The patch creates a new CONSTRAINT_NOTNULL contype and assigns all
required information for the NOT NULL constraint to it. Currently the
--On 4. November 2009 09:57:27 -0500 Tom Lane t...@sss.pgh.pa.us wrote:
Yeah, this is a known issue. The ALTER should be rejected, but it is
not, because we don't have enough infrastructure to notice that the
constraint is inherited and logically can't be dropped. I think the
consensus was
On Thu, Nov 12, 2009 at 11:56, Bernd Helmle maili...@oopsware.de wrote:
I've just started looking into this and wonder how this should look like.
IIRC another motivation for moving them into pg_constraint was we
could then give them names as required by the spec (unless I got mixed
up with
Alex Hunsaker bada...@gmail.com writes:
FYI defaults have the same problem. Would it be awkward would it be
to use pg_constraint for the book keeping as well? [ and by that I
really mean ALTER TABLE ADD CONSTRAINT my_default DEFAULT so you
can give them a name ]
That sounds moderately
On Mon, Nov 16, 2009 at 11:45, Tom Lane t...@sss.pgh.pa.us wrote:
Alex Hunsaker bada...@gmail.com writes:
FYI defaults have the same problem. Would it be awkward would it be
to use pg_constraint for the book keeping as well? [ and by that I
really mean ALTER TABLE ADD CONSTRAINT my_default
--On 16. November 2009 11:00:33 -0700 Alex Hunsaker bada...@gmail.com
wrote:
Anyway Bernd if you are working on this great! If not lemme know, Ill
plan on having something for the next commit feast. Though I still
may never get around to it :(.
I'm just working on it.
The current patch
--On 4. November 2009 09:57:27 -0500 Tom Lane t...@sss.pgh.pa.us wrote:
I think the
consensus was that the way to fix this (along with some other problems)
is to start representing NOT NULL constraints in pg_constraint, turning
attnotnull into just a bit of denormalization for performance.
Bernd Helmle maili...@oopsware.de writes:
My first idea is to just introduce a special contype in pg_constraint
representing a NOT NULL constraint on a column, which holds all required
information to do the mentioned maintenance stuff on them and to keep most
of the current infrastructure.
On Thu, Nov 12, 2009 at 13:55, Tom Lane t...@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
Alex Hunsaker bada...@gmail.com writes:
On Thu, Nov 12, 2009 at 13:55, Tom Lane t...@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
I just run across an issue with ALTER TABLE and inheritance (i don't know
wether this is of the same kind of issue KaiGai reported today, so i keep
it on a separate thread).
Consider the following workflow:
CREATE TABLE foo(id integer NOT NULL, val text NOT NULL);
CREATE TABLE
Bernd Helmle maili...@oopsware.de writes:
Consider the following workflow:
CREATE TABLE foo(id integer NOT NULL, val text NOT NULL);
CREATE TABLE foo2(another_id integer NOT NULL) INHERITS(foo);
Now someone decides he doesn't want the NOT NULL constraint on the
inherited column val
--On 4. November 2009 09:57:27 -0500 Tom Lane t...@sss.pgh.pa.us wrote:
I think the
consensus was that the way to fix this (along with some other problems)
is to start representing NOT NULL constraints in pg_constraint, turning
attnotnull into just a bit of denormalization for performance.
16 matches
Mail list logo
