Excerpts from Robert Haas's message of lun jun 27 10:35:59 -0400 2011:
On Mon, Jun 27, 2011 at 3:08 AM, Dean Rasheed dean.a.rash...@gmail.com
wrote:
I would summarise the consistency requirements as:
1). ADD CONSTRAINT should leave both parent and child tables in the
same state as they
On Wed, Jun 29, 2011 at 12:51 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of lun jun 27 10:35:59 -0400 2011:
On Mon, Jun 27, 2011 at 3:08 AM, Dean Rasheed dean.a.rash...@gmail.com
wrote:
I would summarise the consistency requirements as:
1).
Excerpts from Robert Haas's message of mié jun 29 13:07:25 -0400 2011:
On Wed, Jun 29, 2011 at 12:51 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of lun jun 27 10:35:59 -0400 2011:
Interesting. This whole thing requires quite a bit of rejiggering
On Wed, Jun 29, 2011 at 4:59 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of mié jun 29 13:07:25 -0400 2011:
On Wed, Jun 29, 2011 at 12:51 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of lun jun 27
Excerpts from Robert Haas's message of mié jun 29 18:16:20 -0400 2011:
On Wed, Jun 29, 2011 at 4:59 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of mié jun 29 13:07:25 -0400 2011:
On Wed, Jun 29, 2011 at 12:51 PM, Alvaro Herrera
On 27 June 2011 03:31, Robert Haas robertmh...@gmail.com wrote:
On Sat, Jun 25, 2011 at 2:15 AM, Dean Rasheed dean.a.rash...@gmail.com
wrote:
Really? I would expect the reverse, namely that the not-nullness is
part of the PK constraint and dropping the PK *would* then start
allowing NULLs.
On Mon, Jun 27, 2011 at 3:08 AM, Dean Rasheed dean.a.rash...@gmail.com wrote:
On 27 June 2011 03:31, Robert Haas robertmh...@gmail.com wrote:
On Sat, Jun 25, 2011 at 2:15 AM, Dean Rasheed dean.a.rash...@gmail.com
wrote:
Really? I would expect the reverse, namely that the not-nullness is
part
On Sat, Jun 25, 2011 at 2:15 AM, Dean Rasheed dean.a.rash...@gmail.com wrote:
Really? I would expect the reverse, namely that the not-nullness is
part of the PK constraint and dropping the PK *would* then start
allowing NULLs.
Hmm, OK. I had assumed we were only trying to fix the problem that
On 25 June 2011 01:59, Alvaro Herrera alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of vie jun 24 19:01:49 -0400 2011:
I would tend to think of the not-null-ness that is required by the
primary constraint as a separate constraint, not an intrinsic part of
the primary
Another thing I just noticed is that if you pg_upgrade from a previous
release, all the NOT NULL pg_constraint rows are going to be missing.
I'm not sure what's the best way to deal with this -- should we just
provide a script for the user to run on each database?
--
Álvaro Herrera
On Fri, Jun 24, 2011 at 11:17 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Another thing I just noticed is that if you pg_upgrade from a previous
release, all the NOT NULL pg_constraint rows are going to be missing.
Uh, really? pg_upgrade uses SQL commands to recreate the contents of
Excerpts from Robert Haas's message of vie jun 24 12:06:17 -0400 2011:
On Fri, Jun 24, 2011 at 11:17 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Another thing I just noticed is that if you pg_upgrade from a previous
release, all the NOT NULL pg_constraint rows are going to be
--On 24. Juni 2011 12:06:17 -0400 Robert Haas robertmh...@gmail.com wrote:
Uh, really? pg_upgrade uses SQL commands to recreate the contents of
the system catalogs, so if these entries aren't getting created
automatically, that sounds like a bug in the patch...
AFAIR, i've tested it and it
Excerpts from Bernd Helmle's message of vie jun 24 12:56:26 -0400 2011:
--On 24. Juni 2011 12:06:17 -0400 Robert Haas robertmh...@gmail.com wrote:
Uh, really? pg_upgrade uses SQL commands to recreate the contents of
the system catalogs, so if these entries aren't getting created
So remind me ... did we discuss PRIMARY KEY constraints? Are they
supposed to show up as inherited not null rows in the child? Obviously,
they do not show up as PKs in the child, but they *are* not null so my
guess is that they need to be inherited as not null as well. (Right
now, unpatched
On Fri, Jun 24, 2011 at 6:39 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
So remind me ... did we discuss PRIMARY KEY constraints? Are they
supposed to show up as inherited not null rows in the child? Obviously,
they do not show up as PKs in the child, but they *are* not null so my
Excerpts from Robert Haas's message of vie jun 24 19:01:49 -0400 2011:
On Fri, Jun 24, 2011 at 6:39 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
So remind me ... did we discuss PRIMARY KEY constraints? Are they
supposed to show up as inherited not null rows in the child? Obviously,
Thanks, I am looking at the new version from Bernd's git repo. One
problem I noticed is that it doesn't really work correctly for all
callers of heap_create_with_catalog -- you're only passing the cooked
not null constraints in DefineRelation, but there are some other places
that call
Alvaro Herrera alvhe...@commandprompt.com writes:
So, question: do we need pg_constraint rows to exist for all NOT NULL
constraints, including those in system catalogs, and including those in
bootstrap catalogs? If we're going to require that, we're going to need
to add a few initial data
On Thu, Jun 16, 2011 at 1:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Possible solution is to leave bootstrap's behavior alone, and have a
step during initdb's post-bootstrap stuff that creates a matching
pg_constraint row for every pg_attribute entry that's marked attnotnull.
That seems like a
--On 16. Juni 2011 13:25:05 -0400 Tom Lane t...@sss.pgh.pa.us wrote:
Possible solution is to leave bootstrap's behavior alone, and have a
step during initdb's post-bootstrap stuff that creates a matching
pg_constraint row for every pg_attribute entry that's marked attnotnull.
+1 for this
Excerpts from Bernd Helmle's message of jue jun 16 14:30:48 -0400 2011:
--On 16. Juni 2011 13:25:05 -0400 Tom Lane t...@sss.pgh.pa.us wrote:
Possible solution is to leave bootstrap's behavior alone, and have a
step during initdb's post-bootstrap stuff that creates a matching
I intend to have a look at this patch and hopefully fix the outstanding
issues.
--
Álvaro Herrera alvhe...@commandprompt.com
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via pgsql-hackers mailing list
Bernd, are you still working on this?
On fre, 2010-10-15 at 13:36 -0400, Tom Lane wrote:
Bernd Helmle maili...@oopsware.de writes:
Here is an updated version of the patch. It fixes the following issues
Andrew discovered during his review cycle:
I looked through this a bit. It's not
On fre, 2010-10-15 at 22:45 +0200, Dimitri Fontaine wrote:
I suppose people using other editors or tools will come up with other
tricks and tips.
Here is an alternative recipe that I have been using:
(require 'show-wspace)
(add-hook 'font-lock-mode-hook 'show-ws-highlight-hard-spaces)
--On 16. Oktober 2010 12:35:06 +0300 Peter Eisentraut pete...@gmx.net
wrote:
Maybe it should go in src/tools/editors/emacs.samples, too?
Yeah, I think we should recommend some way to highlight faulty
whitespace.
The problem is, after you turn it on, it will make you cry as you
realize
--On 14. Oktober 2010 20:47:27 +0100 Dean Rasheed
dean.a.rash...@gmail.com wrote:
OK, here it is.
I've not cured this compiler warning (in fact I'm not sure what it's
complaining about, because the variable *is* used):
tablecmds.c: In function 'ATExecSetNotNull':
tablecmds.c:4747:
On 15 October 2010 08:32, Bernd Helmle maili...@oopsware.de wrote:
--On 14. Oktober 2010 20:47:27 +0100 Dean Rasheed dean.a.rash...@gmail.com
wrote:
OK, here it is.
I've not cured this compiler warning (in fact I'm not sure what it's
complaining about, because the variable *is* used):
On Fri, Oct 15, 2010 at 4:06 AM, Dean Rasheed dean.a.rash...@gmail.com wrote:
If these were the only problems with this patch, given that they
required only trivial changes to initialise variables to NIL/false,
perhaps it was premature to mark it as returned with feedback.
Sure. Is someone
The new patch applies cleanly to head, there are no compile errors and
all the make check tests pass (linux).
Thanks
Andrew
On Thu, Oct 14, 2010 at 4:35 PM, Bernd Helmle maili...@oopsware.de wrote:
--On 14. Oktober 2010 16:28:51 -0300 Alvaro Herrera
alvhe...@commandprompt.com wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Oct 15, 2010 at 4:06 AM, Dean Rasheed dean.a.rash...@gmail.com
wrote:
If these were the only problems with this patch, given that they
required only trivial changes to initialise variables to NIL/false,
perhaps it was premature to mark it as
Bernd Helmle maili...@oopsware.de writes:
Here is an updated version of the patch. It fixes the following issues
Andrew discovered during his review cycle:
I looked through this a bit. It's not ready to commit unfortunately.
The main gripe I've got is that you've paid very little attention to
Tom Lane t...@sss.pgh.pa.us writes:
* Lots of bogus trailing whitespace. git diff --check can help you
with that.
This is a repetitive common remark that I think sharing tips to avoid
that problem is a good idea. Here's an emacs setup to have trailing
whitespace hurt the eyes, and more-than-80
--On 15. Oktober 2010 13:36:38 -0400 Tom Lane t...@sss.pgh.pa.us wrote:
Bernd Helmle maili...@oopsware.de writes:
Here is an updated version of the patch. It fixes the following issues
Andrew discovered during his review cycle:
I looked through this a bit. It's not ready to commit
On Tue, Oct 5, 2010 at 4:57 PM, Bernd Helmle maili...@oopsware.de wrote:
--On 30. September 2010 10:12:48 +0200 Bernd Helmle maili...@oopsware.de
wrote:
Yeah, there where some changes in the meantime to the master which
generate some merge failures...will provide a new version along with
I'll post it sometime tomorrow...
Thanks
Andrew
On Wed, Oct 13, 2010 at 9:25 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Oct 5, 2010 at 4:57 PM, Bernd Helmle maili...@oopsware.de wrote:
--On 30. September 2010 10:12:48 +0200 Bernd Helmle maili...@oopsware.de
wrote:
Yeah, there where
Below is my review of the latest iteration of the Extend NOT NULL
Representation to pg_constraint patch found here:
http://archives.postgresql.org/message-id/e57a252dfd60c1fca9173...@amenophis
Thanks
Andrew
On Thu, Oct 14, 2010 at 10:02 AM, Andrew Geery andrew.ge...@gmail.com wrote:
I didn’t have much time to look at the code. The only thing I’ll
mention is that there are a couple of XXX TODO items that should be
cleared up.
[...]
Since this patch actually makes inheritance behave in a more
On 14 October 2010 16:42, Robert Haas robertmh...@gmail.com wrote:
In view of the fact that we are out of time for this CommitFest, ...
When is the official end of this commitfest?
I remember talk at the start, that the end would be postponed (by a
week?) due to time spent on the git migration.
--On 14. Oktober 2010 11:42:27 -0400 Robert Haas robertmh...@gmail.com
wrote:
I did a sanity make clean make make check before applying the
patch and all the tests passed. After applying the patch and doing
make clean make make check, I got a number of failures of the
form “FAILED
--On 14. Oktober 2010 10:02:12 -0400 Andrew Geery andrew.ge...@gmail.com
wrote:
The first failure I get is in the inherit tests (tail of
/src/test/regress/results/inherit.out):
alter table a alter column aa type integer using bit_length(aa);
server closed the connection unexpectedly
On 14 October 2010 17:40, Bernd Helmle maili...@oopsware.de wrote:
--On 14. Oktober 2010 11:42:27 -0400 Robert Haas robertmh...@gmail.com
wrote:
I did a sanity make clean make make check before applying the
patch and all the tests passed. After applying the patch and doing
make clean
Looking in that function, there is a similar found variable that
isn't being initialised (which my compiler didn't warn about).
Initialising that to false, sems to fix the problem and all the
regression tests then pass.
Excellent. Please send an updated patch.
--
Álvaro Herrera
--On 14. Oktober 2010 19:16:56 +0100 Dean Rasheed
dean.a.rash...@gmail.com wrote:
Program received signal SIGSEGV, Segmentation fault.
ATExecSetNotNullInternal (is_local=1 '\001',
is_new_constraint=value optimized out, atttup=value optimized out,
attr_rel=value optimized out,
Excerpts from Bernd Helmle's message of jue oct 14 16:44:36 -0300 2010:
Yepp, that was it. I had a CFLAGS='-O0' in my dev build from a former
debugging cycle and forgot about it (which reminds me to do a
maintainer-clean more often between coding). This is also the reason i
haven't seen
--On 29. September 2010 23:05:11 -0400 Andrew Geery
andrew.ge...@gmail.com wrote:
Reference: https://commitfest.postgresql.org/action/patch_view?id=312
The patch from
http://archives.postgresql.org/message-id/ca2e4c4762eae28d68404...@amenop
his does not apply cleanly to the current git
Ok -- I've updated the commitfest page linking in this review and
changing the status to waiting on a new patch from you.
Thanks
Andrew
On Thu, Sep 30, 2010 at 4:12 AM, Bernd Helmle maili...@oopsware.de wrote:
--On 29. September 2010 23:05:11 -0400 Andrew Geery andrew.ge...@gmail.com
wrote:
47 matches
Mail list logo
