Excerpts from Kevin Grittner's message of jue ago 02 10:48:02 -0400 2012:
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
Don't forget the peculiarities of columns with record types.
I forgot to include the type creation in the example:
test=# create type a as (a1 int, a2 int);
Alvaro Herrera alvhe...@2ndquadrant.com wrote:
I think that a NOT NULL constraint attached to a column with a
composite type is equivalent to a CHECK (col IS DISTINCT FROM
NULL); at least they seem to behave identically. Is that what you
would expect?
I had not thought about that, but now
On Fri, Jul 22, 2011 at 12:14:30PM -0400, Robert Haas wrote:
On Thu, Jul 21, 2011 at 7:51 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
I think that there probably ought to be a way to display the NOT NULL
constraint names (perhaps through \d+). For example, if you're
planning to
Alvaro Herrera alvhe...@commandprompt.com wrote:
Just over a year ago, I posted a patch (based on a previous patch
by Bernd Helmle) that attempted to add pg_constraint rows for NOT
NULL
constraints.
http://archives.postgresql.org/message-id/20110707213401.ga27...@alvh.no-ip.org
That
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
Don't forget the peculiarities of columns with record types.
I forgot to include the type creation in the example:
test=# create type a as (a1 int, a2 int);
CREATE TYPE
-Kevin
--
Sent via pgsql-hackers mailing list
On lör, 2011-08-06 at 12:58 +0100, Dean Rasheed wrote:
Right now \d gives:
Table public.foo
Column | Type | Modifiers
+-+---
a | integer | not null
b | integer |
c | integer |
Check constraints:
foo_b_check CHECK (b IS NOT NULL)
On 4 August 2011 18:57, Peter Eisentraut pete...@gmx.net wrote:
Have you considered just cataloging NOT NULL constraints as CHECK
constraints and teaching the reverse parser to convert x CHECK (x IS
NOT NULL) to x NOT NULL. It seems to me that we're adding a whole
lot of hoopla here that is
On 6 August 2011 01:01, Peter Eisentraut pete...@gmx.net wrote:
Before embarking on rewriting this patch from scratch, I would like to
know what's your opinion (or the SQL standard's) on the fact that this
patch separated the PRIMARY KEY from NOT NULL constraints, so that they
don't act
On 6 August 2011 08:17, Dean Rasheed dean.a.rash...@gmail.com wrote:
The current behaviour is inconsistent - the not-null property of a PK
is sometimes inherited and sometimes not, depending on whether the PK
is added at table-creation time or later.
Oops, that should have been depending on
On lör, 2011-08-06 at 08:04 +0100, Dean Rasheed wrote:
On 4 August 2011 18:57, Peter Eisentraut pete...@gmx.net wrote:
Have you considered just cataloging NOT NULL constraints as CHECK
constraints and teaching the reverse parser to convert x CHECK (x IS
NOT NULL) to x NOT NULL. It seems to
On lör, 2011-08-06 at 08:17 +0100, Dean Rasheed wrote:
The current behaviour is inconsistent - the not-null property of a PK
is sometimes inherited and sometimes not, depending on whether the PK
is added at table-creation time or later. So a change in either
direction is a change to some
On 6 August 2011 11:03, Peter Eisentraut pete...@gmx.net wrote:
On lör, 2011-08-06 at 08:04 +0100, Dean Rasheed wrote:
On 4 August 2011 18:57, Peter Eisentraut pete...@gmx.net wrote:
Have you considered just cataloging NOT NULL constraints as CHECK
constraints and teaching the reverse parser
Dean Rasheed dean.a.rash...@gmail.com writes:
[ wonders what psql's \d will do with NOT NULL constraints ]
I think this might be taking the notion of it should be backwards
compatible too far. We're not expecting this patch to not change
the wording of error messages, for instance (in fact, I
On tor, 2011-08-04 at 16:15 -0400, Alvaro Herrera wrote:
Have you considered just cataloging NOT NULL constraints as CHECK
constraints and teaching the reverse parser to convert x CHECK (x IS
NOT NULL) to x NOT NULL.
Hmm, no, I admit I haven't. The current approach was suggested very
Peter Eisentraut pete...@gmx.net writes:
On tor, 2011-08-04 at 16:15 -0400, Alvaro Herrera wrote:
Yeah, perhaps you're right. The main reason they were considered
separately is that we wanted to have them to be optimized via
pg_attribute.attnotnull, but my patch does away with the need for
Excerpts from Tom Lane's message of vie ago 05 21:23:41 -0400 2011:
Peter Eisentraut pete...@gmx.net writes:
On tor, 2011-08-04 at 16:15 -0400, Alvaro Herrera wrote:
Yeah, perhaps you're right. The main reason they were considered
separately is that we wanted to have them to be optimized
On 3 August 2011 22:26, Alvaro Herrera alvhe...@commandprompt.com wrote:
Excerpts from Dean Rasheed's message of sáb jul 23 04:37:06 -0400 2011:
On 22 July 2011 22:28, Robert Haas robertmh...@gmail.com wrote:
mine was that we need a command such as
ALTER TABLE foo ALTER COLUMN bar SET NOT
So after writing the code to handle named NOT NULL constraints for
tables, I'm thinking that dumpConstraints needs to be fixed thusly:
@@ -12888,6 +12968,27 @@ dumpConstraint(Archive *fout, ConstraintInfo
*coninfo)
NULL, NULL);
}
}
+ else if
On 4 August 2011 09:23, Nikhil Sontakke nikkh...@gmail.com wrote:
So after writing the code to handle named NOT NULL constraints for
tables, I'm thinking that dumpConstraints needs to be fixed thusly:
@@ -12888,6 +12968,27 @@ dumpConstraint(Archive *fout, ConstraintInfo
*coninfo)
Excerpts from Nikhil Sontakke's message of jue ago 04 04:23:59 -0400 2011:
Some nit-picking.
AFAICS above, we seem to be only using 'tbinfo' to identify the object
type here - 'table' visavis 'domain'. We could probably reduce the
above two elses to a single one and use the check of tbinfo
On tis, 2011-08-02 at 23:40 -0400, Alvaro Herrera wrote:
Thanks. I've done the other changes you suggested, but I don't see that
it's desirable to have gram.y emit AT_AddConstraint directly. It seems
cleaner to be able to turn a NOT NULL constraint into AT_SetNotNull
in parse_utilcmd
Excerpts from Peter Eisentraut's message of jue ago 04 13:57:54 -0400 2011:
On tis, 2011-08-02 at 23:40 -0400, Alvaro Herrera wrote:
Thanks. I've done the other changes you suggested, but I don't see that
it's desirable to have gram.y emit AT_AddConstraint directly. It seems
cleaner to be
On 3 August 2011 04:40, Alvaro Herrera alvhe...@commandprompt.com wrote:
Excerpts from Dean Rasheed's message of sáb jul 30 18:40:46 -0400 2011:
Looks pretty good to me (not too dirty). I suppose given that the
parser transforms AT_ColumnConstraint into one of the existing command
subtypes,
Excerpts from Dean Rasheed's message of mié ago 03 03:11:32 -0400 2011:
On 3 August 2011 04:40, Alvaro Herrera alvhe...@commandprompt.com wrote:
Excerpts from Dean Rasheed's message of sáb jul 30 18:40:46 -0400 2011:
Looks pretty good to me (not too dirty). I suppose given that the
parser
Excerpts from Alvaro Herrera's message of mié ago 03 13:12:38 -0400 2011:
... ah, maybe what we could do is have gram.y create a ColumnDef in the
new production, and stick that in cmd-def instead of the list of
constraints. So parse_utilcmd would have to know that if that node
IsA(ColumnDef)
Excerpts from Dean Rasheed's message of sáb jul 23 04:37:06 -0400 2011:
On 22 July 2011 22:28, Robert Haas robertmh...@gmail.com wrote:
mine was that we need a command such as
ALTER TABLE foo ALTER COLUMN bar SET NOT NULL name_of_notnull_constr
where the last bit is what's new.
Excerpts from Dean Rasheed's message of sáb jul 30 18:40:46 -0400 2011:
Looks pretty good to me (not too dirty). I suppose given that the
parser transforms AT_ColumnConstraint into one of the existing command
subtypes, you could just have gram.y emit an AT_AddConstraint with the
ColumnDef
On 30 July 2011 01:23, Alvaro Herrera alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of sáb jul 23 07:40:12 -0400 2011:
On Sat, Jul 23, 2011 at 4:37 AM, Dean Rasheed dean.a.rash...@gmail.com
wrote:
That looks wrong to me, because a NOT NULL constraint is a column
Excerpts from Robert Haas's message of sáb jul 23 07:40:12 -0400 2011:
On Sat, Jul 23, 2011 at 4:37 AM, Dean Rasheed dean.a.rash...@gmail.com
wrote:
That looks wrong to me, because a NOT NULL constraint is a column
constraint not a table constraint. The CREATE TABLE syntax explicitly
On 22 July 2011 22:28, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jul 22, 2011 at 4:39 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of vie jul 22 12:14:30 -0400 2011:
On Thu, Jul 21, 2011 at 7:51 PM, Alvaro Herrera
alvhe...@commandprompt.com
On Sat, Jul 23, 2011 at 4:37 AM, Dean Rasheed dean.a.rash...@gmail.com wrote:
That looks wrong to me, because a NOT NULL constraint is a column
constraint not a table constraint. The CREATE TABLE syntax explicitly
distinguishes these 2 cases, and only allows NOT NULLs in column
constraints. So
On Thu, Jul 21, 2011 at 7:51 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
I think that there probably ought to be a way to display the NOT NULL
constraint names (perhaps through \d+). For example, if you're
planning to support NOT VALID on top of this in the future, then there
needs to
On ons, 2011-07-20 at 13:53 -0400, Alvaro Herrera wrote:
I checked the check_constraints definition in the standard and it's
not clear to me that NOT NULL constraints are supposed to be there at
all. Are NOT NULL constraints considered to be CHECK constraints too?
Yes, NOT NULL is considered
Excerpts from Robert Haas's message of vie jul 22 12:14:30 -0400 2011:
On Thu, Jul 21, 2011 at 7:51 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
I think that there probably ought to be a way to display the NOT NULL
constraint names (perhaps through \d+). For example, if you're
On Fri, Jul 22, 2011 at 4:39 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of vie jul 22 12:14:30 -0400 2011:
On Thu, Jul 21, 2011 at 7:51 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
I think that there probably ought to be a way to display
Excerpts from Peter Eisentraut's message of sáb jul 09 14:45:23 -0400 2011:
On tor, 2011-07-07 at 17:34 -0400, Alvaro Herrera wrote:
The attached patch introduces pg_constraint rows for NOT NULL
column constraints.
The information schema views check_constraints and table_constraints
On 7 July 2011 22:34, Alvaro Herrera alvhe...@commandprompt.com wrote:
Hi,
The attached patch introduces pg_constraint rows for NOT NULL
column constraints.
This patch is a heavily reworked version of Bernd Helmle's patch here:
On tor, 2011-07-07 at 17:34 -0400, Alvaro Herrera wrote:
The attached patch introduces pg_constraint rows for NOT NULL
column constraints.
The information schema views check_constraints and table_constraints
currently make up some artificial constraint names for not-null
constraints. I suppose
Excerpts from Robert Haas's message of vie jul 08 23:30:10 -0400 2011:
On Thu, Jul 7, 2011 at 5:34 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
The attached patch introduces pg_constraint rows for NOT NULL
column constraints.
This patch is a heavily reworked version of Bernd
On Thu, Jul 7, 2011 at 5:34 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
The attached patch introduces pg_constraint rows for NOT NULL
column constraints.
This patch is a heavily reworked version of Bernd Helmle's patch here:
40 matches
Mail list logo
