pg.ddx.io  pgsql-sql@postgresql.org mailing list archive  
help / color / mirror / Atom feed
Re: [SQL] ARRAY() returning NULL instead of ARRAY[]
4+ messages / 3 participants
[nested] [flat]

* Re: [SQL] ARRAY() returning NULL instead of ARRAY[]
@ 2005-06-06 16:12 Markus Bertheau ☭ <twanger@bluetwanger.de>
  2005-06-25 01:50 ` Re: [SQL] ARRAY() returning NULL instead of ARRAY[] Bruce Momjian <pgman@candle.pha.pa.us>
  0 siblings, 1 reply; 4+ messages in thread

From: Markus Bertheau ☭ @ 2005-06-06 16:12 UTC (permalink / raw)
  To: Joe Conway <mail@joeconway.com>; +Cc: pgsql-hackers@postgresql.org, Tom Lane <tgl@sss.pgh.pa.us>

В Пнд, 06/06/2005 в 08:58 -0700, Joe Conway пишет:
> Joe Conway wrote:
> > Actually, consistent with my last post, I think array_upper() on a 
> > zero-element array should return NULL. A zero-element array has a 
> > defined lower bound, but its upper bound is not zero -- it is really 
> > undefined.
> 
> Just to clarify my response, this is what I propose:
> 
> regression=# select array_upper('[2][1:]={{},{}}'::int[],1);
>   array_upper
> -------------
>             2
> (1 row)
> 
> regression=# select array_upper('[2][1:]={{},{}}'::int[],2) IS NULL;
>   ?column?
> ----------
>   t
> (1 row)

Hmm, this gets really complicated and inconsistent. Complicated means
unusable. What about modifying the dimension syntax such that the second
number means number of elements instead of upper bound? That particular
problem would go away then, and array_upper('[0:0]={}'::int[]) can
return the correct 0 then.

What I'm actually worrying about is that array_upper(array(select 1
where false)) returns 0.

An option would be to drop the possibility to let the array start at
another index than 0. I don't know why it was decided to do that in the
first place. It seems a rather odd feature to me.

Markus
-- 
Markus Bertheau ☭ <twanger@bluetwanger.de>




^ permalink  raw  reply  [nested|flat] 4+ messages in thread

* Re: [SQL] ARRAY() returning NULL instead of ARRAY[]
  2005-06-06 16:12 Re: [SQL] ARRAY() returning NULL instead of ARRAY[] Markus Bertheau ☭ <twanger@bluetwanger.de>
@ 2005-06-25 01:50 ` Bruce Momjian <pgman@candle.pha.pa.us>
  2005-06-27 04:08   ` Re: [SQL] ARRAY() returning NULL instead of ARRAY[] Joe Conway <mail@joeconway.com>
  0 siblings, 1 reply; 4+ messages in thread

From: Bruce Momjian @ 2005-06-25 01:50 UTC (permalink / raw)
  To: Markus Bertheau ? <twanger@bluetwanger.de>; +Cc: Joe Conway <mail@joeconway.com>; pgsql-hackers@postgresql.org, Tom Lane <tgl@sss.pgh.pa.us>


Is this a TODO item?

---------------------------------------------------------------------------

Markus Bertheau ? wrote:
> ? ???, 06/06/2005 ? 08:58 -0700, Joe Conway ?????:
> > Joe Conway wrote:
> > > Actually, consistent with my last post, I think array_upper() on a 
> > > zero-element array should return NULL. A zero-element array has a 
> > > defined lower bound, but its upper bound is not zero -- it is really 
> > > undefined.
> > 
> > Just to clarify my response, this is what I propose:
> > 
> > regression=# select array_upper('[2][1:]={{},{}}'::int[],1);
> >   array_upper
> > -------------
> >             2
> > (1 row)
> > 
> > regression=# select array_upper('[2][1:]={{},{}}'::int[],2) IS NULL;
> >   ?column?
> > ----------
> >   t
> > (1 row)
> 
> Hmm, this gets really complicated and inconsistent. Complicated means
> unusable. What about modifying the dimension syntax such that the second
> number means number of elements instead of upper bound? That particular
> problem would go away then, and array_upper('[0:0]={}'::int[]) can
> return the correct 0 then.
> 
> What I'm actually worrying about is that array_upper(array(select 1
> where false)) returns 0.
> 
> An option would be to drop the possibility to let the array start at
> another index than 0. I don't know why it was decided to do that in the
> first place. It seems a rather odd feature to me.
> 
> Markus
> -- 
> Markus Bertheau ? <twanger@bluetwanger.de>
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
>       subscribe-nomail command to majordomo@postgresql.org so that your
>       message can get through to the mailing list cleanly
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073



^ permalink  raw  reply  [nested|flat] 4+ messages in thread

* Re: [SQL] ARRAY() returning NULL instead of ARRAY[]
  2005-06-06 16:12 Re: [SQL] ARRAY() returning NULL instead of ARRAY[] Markus Bertheau ☭ <twanger@bluetwanger.de>
  2005-06-25 01:50 ` Re: [SQL] ARRAY() returning NULL instead of ARRAY[] Bruce Momjian <pgman@candle.pha.pa.us>
@ 2005-06-27 04:08   ` Joe Conway <mail@joeconway.com>
  2005-06-27 09:39     ` Re: [SQL] ARRAY() returning NULL instead of ARRAY[] Bruce Momjian <pgman@candle.pha.pa.us>
  0 siblings, 1 reply; 4+ messages in thread

From: Joe Conway @ 2005-06-27 04:08 UTC (permalink / raw)
  To: Bruce Momjian <pgman@candle.pha.pa.us>; +Cc: Markus Bertheau ? <twanger@bluetwanger.de>; pgsql-hackers@postgresql.org, Tom Lane <tgl@sss.pgh.pa.us>

Bruce Momjian wrote:
> Is this a TODO item?
> 

Probably. I posted some questions regarding whether or not to break 
backward compatiblity, and received no replies. In the meanwhile, I've 
been doing a major system integration in Korea for the last 2 weeks, and 
won't get back to home, or to anything like a reasonably normal schedule 
until after July 2. I doubt I'll have time to do much between now and 
feature freeze.

Joe



^ permalink  raw  reply  [nested|flat] 4+ messages in thread

* Re: [SQL] ARRAY() returning NULL instead of ARRAY[]
  2005-06-06 16:12 Re: [SQL] ARRAY() returning NULL instead of ARRAY[] Markus Bertheau ☭ <twanger@bluetwanger.de>
  2005-06-25 01:50 ` Re: [SQL] ARRAY() returning NULL instead of ARRAY[] Bruce Momjian <pgman@candle.pha.pa.us>
  2005-06-27 04:08   ` Re: [SQL] ARRAY() returning NULL instead of ARRAY[] Joe Conway <mail@joeconway.com>
@ 2005-06-27 09:39     ` Bruce Momjian <pgman@candle.pha.pa.us>
  0 siblings, 0 replies; 4+ messages in thread

From: Bruce Momjian @ 2005-06-27 09:39 UTC (permalink / raw)
  To: Joe Conway <mail@joeconway.com>; +Cc: Markus Bertheau ? <twanger@bluetwanger.de>; pgsql-hackers@postgresql.org, Tom Lane <tgl@sss.pgh.pa.us>


OK, what is the TODO item text?

---------------------------------------------------------------------------

Joe Conway wrote:
> Bruce Momjian wrote:
> > Is this a TODO item?
> > 
> 
> Probably. I posted some questions regarding whether or not to break 
> backward compatiblity, and received no replies. In the meanwhile, I've 
> been doing a major system integration in Korea for the last 2 weeks, and 
> won't get back to home, or to anything like a reasonably normal schedule 
> until after July 2. I doubt I'll have time to do much between now and 
> feature freeze.
> 
> Joe
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073



^ permalink  raw  reply  [nested|flat] 4+ messages in thread


end of thread, other threads:[~2005-06-27 09:39 UTC | newest]

Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2005-06-06 16:12 Re: [SQL] ARRAY() returning NULL instead of ARRAY[] Markus Bertheau ☭ <twanger@bluetwanger.de>
2005-06-25 01:50 ` Bruce Momjian <pgman@candle.pha.pa.us>
2005-06-27 04:08   ` Joe Conway <mail@joeconway.com>
2005-06-27 09:39     ` Bruce Momjian <pgman@candle.pha.pa.us>

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox