Alvaro Herrera 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 that you point it ou
Excerpts from Kevin Grittner's message of jue ago 02 10:48:02 -0400 2012:
>
> "Kevin Grittner" 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
Th
On Fri, Jul 22, 2011 at 12:14:30PM -0400, Robert Haas wrote:
> On Thu, Jul 21, 2011 at 7:51 PM, Alvaro Herrera
> 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
"Kevin Grittner" 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 (pgsql-hackers@postgresql.org)
To make changes
Alvaro Herrera 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 patch was rather long and
Hello,
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 patch was rather long and complex, as it tried to hand
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
Dean Rasheed 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 think a large
part of t
On 6 August 2011 11:03, Peter Eisentraut wrote:
> On lör, 2011-08-06 at 08:04 +0100, Dean Rasheed wrote:
>> On 4 August 2011 18:57, Peter Eisentraut wrote:
>> > Have you considered just cataloging NOT NULL constraints as CHECK
>> > constraints and teaching the reverse parser to convert "x CHECK (
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 cu
On lör, 2011-08-06 at 08:04 +0100, Dean Rasheed wrote:
> On 4 August 2011 18:57, Peter Eisentraut 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 t
On 6 August 2011 08:17, 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.
>
Oops, that should have been "depending on whether the PK is def
On 6 August 2011 01:01, Peter Eisentraut 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 exactly alike
On 4 August 2011 18:57, Peter Eisentraut 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 essential
Excerpts from Tom Lane's message of vie ago 05 21:23:41 -0400 2011:
> Peter Eisentraut 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
> >>
Peter Eisentraut 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 that
>> bec
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 suggest
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
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 inst
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 tbi
On 4 August 2011 09:23, Nikhil Sontakke 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)
>>
> 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 (c
On 3 August 2011 22:26, Alvaro Herrera 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 wrote:
>
>> >> mine was that we need a command such as
>> >>
>> >> ALTER TABLE foo ALTER COLUMN bar SET NOT NULL name_of_notnull_constr
>>
Excerpts from Dean Rasheed's message of sáb jul 23 04:37:06 -0400 2011:
> On 22 July 2011 22:28, Robert Haas 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.
> >
> > Well,
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(Column
Excerpts from Dean Rasheed's message of mié ago 03 03:11:32 -0400 2011:
> On 3 August 2011 04:40, Alvaro Herrera 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_C
On 3 August 2011 04:40, Alvaro Herrera 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, you could just have
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 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
>> wrote:
>> > That looks wrong to me, because a NOT NULL constraint is a column
>> > constraint not a table constraint. The CREA
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
> 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
On Sat, Jul 23, 2011 at 4:37 AM, Dean Rasheed 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 from a consistency p
On 22 July 2011 22:28, Robert Haas wrote:
> On Fri, Jul 22, 2011 at 4:39 PM, Alvaro Herrera
> 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
>>> wrote:
>>> >> I think that there probably ought to be a way to di
On Fri, Jul 22, 2011 at 4:39 PM, Alvaro Herrera
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
>> wrote:
>> >> I think that there probably ought to be a way to display the NOT NULL
>> >> constraint names (perhaps
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
> 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
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 considere
On Thu, Jul 21, 2011 at 7:51 PM, Alvaro Herrera
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 be a way to get th
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 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:
> http://archives.postgresql.org/message-id/E57A252DFD60C1FCA91731BD@amenophis
>
> I
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
> 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:
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 suppos
On Thu, Jul 7, 2011 at 5:34 PM, Alvaro Herrera
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:
> http://archives.postgresql.org/message-id/E57A252DFD60C1FCA91731BD@amenophis
>
>
41 matches
Mail list logo
