Rikard Pavelic rikard.pave...@zg.htnet.hr wrote:
The only inconsistent thing is check constraint, which behaves as
NOT column IS NULL instead of column IS NOT NULL as docs says.
So currently a NOT NULL constraint on a column with a composite type
is equivalent to:
CHECK (NOT c IS NULL)
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Rikard Pavelic rikard.pave...@zg.htnet.hr wrote:
The only inconsistent thing is check constraint, which behaves as
NOT column IS NULL instead of column IS NOT NULL as docs says.
So currently a NOT NULL constraint on a column with a composite
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
So currently a NOT NULL constraint on a column with a composite
type is equivalent to:
CHECK (NOT c IS NULL)
I don't believe this statement is accurate. What's really
happening is that a
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
It's not clear to me whether the SQL standard rules on what should
happen in this case, or whether we should listen to it if it does
say that these values are not distinct. They certainly *look*
distinct.
Tom Lane t...@sss.pgh.pa.us wrote:
The reason I mentioned arrays is that it seems clear to me that
nobody sane would consider ARRAY[NULL,NULL]::int[] to be
equivalent to NULL::int[].
I will defer on that to anyone who has been in a position where the
former has any meaningful semantics in a
The following bug has been logged on the website:
Bug reference: 6701
Logged by: Rikard Pavelic
Email address: rikard.pave...@zg.htnet.hr
PostgreSQL version: 9.1.3
Operating system: Windows 7
Description:
create type t AS (i int);
create type complex as (t t, i int);
Hello
it is not a bug - see
http://archives.postgresql.org/pgsql-hackers/2009-07/msg01525.php
Regards
Pavel Stehule
2012/6/20 rikard.pave...@zg.htnet.hr:
The following bug has been logged on the website:
Bug reference: 6701
Logged by: Rikard Pavelic
Email address:
rikard.pave...@zg.htnet.hr wrote:
--This doesn't work as expected
select * from bad where c is not null;
Are you seeing any behavior which does not match the documentation
and the standard?
http://www.postgresql.org/docs/current/interactive/functions-comparison.html
says:
| Note: If
rikard.pave...@zg.htnet.hr writes:
create type t AS (i int);
create type complex as (t t, i int);
create table bad(i int, c complex);
insert into bad values(1, null);
insert into bad values(1, ROW(null, 2));
insert into bad values(1, ROW(ROW(1), 2));
select * from bad;
select * from bad
On 20.6.2012. 20:55, Pavel Stehule wrote:
Hello
it is not a bug - see
http://archives.postgresql.org/pgsql-hackers/2009-07/msg01525.php
Regards
Pavel Stehule
I found that in documentation after reporting bug.
I'm sorry for not searching some more, but didn't know where to look exactly.
2012/6/20 Rikard Pavelic rikard.pave...@zg.htnet.hr:
On 20.6.2012. 20:55, Pavel Stehule wrote:
Hello
it is not a bug - see
http://archives.postgresql.org/pgsql-hackers/2009-07/msg01525.php
Regards
Pavel Stehule
I found that in documentation after reporting bug.
I'm sorry for not
On 20.6.2012. 21:10, Tom Lane wrote:
rikard.pave...@zg.htnet.hr writes:
create type t AS (i int); create type complex as (t t, i int); create table
bad(i int, c complex); --This doesn't work as expected select * from bad
where c is not null;
What do you consider to be expected? Have you
2012/6/21 Rikard Pavelic rikard.pave...@zg.htnet.hr:
On 20.6.2012. 21:10, Tom Lane wrote:
rikard.pave...@zg.htnet.hr writes:
create type t AS (i int); create type complex as (t t, i int); create table
bad(i int, c complex); --This doesn't work as expected select * from bad
where c is not
13 matches
Mail list logo
