Tom Lane 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 SQL environment
"Kevin Grittner" writes:
> Tom Lane 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.
> I do sympathize with the point o
Tom Lane wrote:
> "Kevin Grittner" 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 column-not-null constraint is a
> datatype-indep
"Kevin Grittner" writes:
> Rikard Pavelic 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 NU
Rikard Pavelic 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)
and the question is whethe
On 21.6.2012. 6:03, Pavel Stehule wrote:
> 2012/6/21 Rikard Pavelic :
>> 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 *
2012/6/21 Rikard Pavelic :
> 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
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"? Ha
2012/6/20 Rikard Pavelic :
> 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
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 ex
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 * fr
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 the expression is row-valu
Hello
it is not a bug - see
http://archives.postgresql.org/pgsql-hackers/2009-07/msg01525.php
Regards
Pavel Stehule
2012/6/20 :
> The following bug has been logged on the website:
>
> Bug reference: 6701
> Logged by: Rikard Pavelic
> Email address: 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
PostgreSQL version: 9.1.3
Operating system: Windows 7
Description:
create type t AS (i int);
create type complex as (t t, i int);
14 matches
Mail list logo