Array constructor requires one argument
Martijn van Oosterhout
Is there a particular reason why the array constructor requires at
least one argument? It's a bit irriating to have to special case zero
length arrays.
# select array[];
ERROR: syntax error at or near "]" at character 14
# select array[1];
array
-------
{1}
(1 row)
# select '{}'::int4[];
int4
------
{}
(1 row)
Have a nice day,
--
Martijn van Oosterhout <kle...@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.
Tom Lane
> Is there a particular reason why the array constructor requires at
> least one argument?
Define the data type of
SELECT ARRAY[];
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majo...@postgresql.org so that your
message can get through to the mailing list cleanly
Martijn van Oosterhout
> Martijn van Oosterhout <kle...@svana.org> writes:
> > Is there a particular reason why the array constructor requires at
> > least one argument?
>
> Define the data type of
>
> SELECT ARRAY[];
The same type as:
SELECT NULL;
or
SELECT '{}';
We allow the deferring of the decision of the type for normal strings,
why not in this case also? In fact, you could just make it an unknown
literal with just two curly vrace and you'd be all set.
Tom Lane
> On Tue, Jan 09, 2007 at 10:02:09AM -0500, Tom Lane wrote:
>> Define the data type of
>> SELECT ARRAY[];
> The same type as:
> SELECT NULL;
Hardly, because whatever type NULL has, it's not an array type.
> In fact, you could just make it an unknown
> literal with just two curly vrace and you'd be all set.
Nope. '{}' without any other decoration isn't an array at all.
You're confusing external representation with what the system
(thinks it) knows about the type of an expression.
As an example, if we did what I think you're proposing, this
would succeed:
SELECT ARRAY[]::text;
whereas it certainly ought not, because there is no cast from
any array type to a scalar text value.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
Joe Conway
> Martijn van Oosterhout <kle...@svana.org> writes:
>
>>On Tue, Jan 09, 2007 at 10:02:09AM -0500, Tom Lane wrote:
>>
>>>Define the data type of
>>>SELECT ARRAY[];
>
>
>>The same type as:
>>SELECT NULL;
>
>
> Hardly, because whatever type NULL has, it's not an array type.
Here's a link to the initial discussion on this topic:
http://archives.postgresql.org/pgsql-hackers/2003-06/msg01195.php
Unless we can convince ourselves that array-of-UNKNOWN is not dangerous,
I don't think this is easily solved.
Joe
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Tom Lane
> Unless we can convince ourselves that array-of-UNKNOWN is not dangerous,
> I don't think this is easily solved.
One possibility that might handle Martijn's problem is to allow the
construct
ARRAY[]::type[]
that is, you can have an empty ARRAY construct only if you immediately
cast it to a specific array type. The application typically knows what
type the data is anyway, and if it just always plasters on the cast then
the syntax would work regardless of whether there are any elements or not.
regards, tom lane
David Fetter
> Joe Conway <ma...@joeconway.com> writes:
> > Unless we can convince ourselves that array-of-UNKNOWN is not dangerous,
> > I don't think this is easily solved.
>
> One possibility that might handle Martijn's problem is to allow the
> construct
>
> ARRAY[]::type[]
>
> that is, you can have an empty ARRAY construct only if you immediately
> cast it to a specific array type. The application typically knows what
> type the data is anyway, and if it just always plasters on the cast then
> the syntax would work regardless of whether there are any elements or not.
+1 for doing it this way :)
Cheers,
D
--
David Fetter <da...@fetter.org> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666
Skype: davidfetter
Remember to vote!
Martijn van Oosterhout
> > Unless we can convince ourselves that array-of-UNKNOWN is not dangerous,
> > I don't think this is easily solved.
>
> One possibility that might handle Martijn's problem is to allow the
> construct
>
> ARRAY[]::type[]
This was in fact the solution I came up with. It also helps with the
confusion, because the error didn't state the actual problem. At least
this could could say "empty array needs typecast".
I don't think it would be too hard to fix, I'll look tomorrow.
Tom Lane
>> One possibility that might handle Martijn's problem is to allow the
>> construct
>> ARRAY[]::type[]
> I don't think it would be too hard to fix, I'll look tomorrow.
It could be pretty ugly, because type assignment normally proceeds
bottom-up :-(. What you might have to do is make the raw grammar
representation of ARRAY[] work like A_Const does, ie, there's a
slot to plug in a typecast. That's pretty much vestigial now for
A_Const, if memory serves, but it'd be needful if ARRAY[] has to
be able to "see" the typecast that would otherwise be above it in
the parse tree.
Come to think of it, there is an additional possible benefit to doing
it this way, which is that if ARRAY[] knows a target array type then
it can just coerce all the elements to that without bothering with
trying to induce a common type. So you should be able to save a few
cycles in the non-empty case, too.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster