On Mon, Sep 21, 2009 at 12:31 PM, Bruce Momjian wrote:
> Sam Mason wrote:
>> On Mon, Sep 14, 2009 at 10:54:07AM -0500, Kevin Grittner wrote:
>> > Sam Mason wrote:
>> > > the deeper problem seems to be that the table was created as:
>> > >
>> > > create table test (a tstdom);
>> > >
>> > > and n
Sam Mason wrote:
> On Mon, Sep 14, 2009 at 10:54:07AM -0500, Kevin Grittner wrote:
> > Sam Mason wrote:
> > > the deeper problem seems to be that the table was created as:
> > >
> > > create table test (a tstdom);
> > >
> > > and not as:
> > >
> > > create table test (a tstdom not null);
>
On Mon, Sep 14, 2009 at 10:22:34AM -0400, Tom Lane wrote:
> Robert Haas writes:
> > It seems like regardless of this discussion you oughtn't to be able to
> > store a NULL into that table column. But maybe I'm just confused.
>
> The system is relying on the not-unreasonable assumption that if it
On Mon, Sep 14, 2009 at 10:54:07AM -0500, Kevin Grittner wrote:
> Sam Mason wrote:
> > the deeper problem seems to be that the table was created as:
> >
> > create table test (a tstdom);
> >
> > and not as:
> >
> > create table test (a tstdom not null);
>
> Given that tstdom is declared a
Sam Mason wrote:
> the deeper problem seems to be that the table was created as:
>
> create table test (a tstdom);
>
> and not as:
>
> create table test (a tstdom not null);
Given that tstdom is declared as NOT NULL, is this difference
considered a *feature* or is it an implementation q
On Mon, Sep 14, 2009 at 11:16:23AM -0400, Robert Haas wrote:
> I haven't read the code in this area, but for what it's worth, I guess
> I lean toward the view that treating a row of NULLs as being the same
> thing as an undecorated NULL does not make very much sense.
I agree; when compared to most
On Mon, Sep 14, 2009 at 10:22 AM, Tom Lane wrote:
> Robert Haas writes:
>> It seems like regardless of this discussion you oughtn't to be able to
>> store a NULL into that table column. But maybe I'm just confused.
>
> The system is relying on the not-unreasonable assumption that if it
> extract
Robert Haas writes:
> It seems like regardless of this discussion you oughtn't to be able to
> store a NULL into that table column. But maybe I'm just confused.
The system is relying on the not-unreasonable assumption that if it
extracts a column of type X from someplace, what it has is a valid
On Sun, Sep 13, 2009 at 10:28 PM, Tom Lane wrote:
> "Andrew Gierth" writes:
>> Domain NOT NULL constraints (and probably other constraints too) aren't
>> being enforced in some code paths. e.g.
>
> The example you give seems to tie really closely into the debate about
> whether a composite null i
"Andrew Gierth" writes:
> Domain NOT NULL constraints (and probably other constraints too) aren't
> being enforced in some code paths. e.g.
The example you give seems to tie really closely into the debate about
whether a composite null is identically the same thing as ROW(NULL,NULL)
or not. In s
The following bug has been logged online:
Bug reference: 5053
Logged by: Andrew Gierth
Email address: and...@tao11.riddles.org.uk
PostgreSQL version: 8.5devel
Operating system: FreeBSD
Description:domain constraints still leak
Details:
Domain NOT NULL constraints (a
11 matches
Mail list logo
