A quick recap: I submitted a patch for empty ARRAY[] syntax back in
November, and as far as I can see it never made it to the patches
list. Gregory suggested a different way of approaching the problem
(quoted below), but nobody commented further about how it might be
made to work.
I'd like to RFC
On Nov 30, 2007 9:09 PM, Gregory Stark <[EMAIL PROTECTED]> wrote:
> I'm sorry to suggest anything at this point, but... would it be less invasive
> if instead of requiring the immediate cast you created a special case in the
> array code to allow a placeholder object for "empty array of unknown typ
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> The patch is very invasive (at least compared to any of my previous
> patches), but so far I haven't managed to find any broken behaviour.
I'm sorry to suggest anything at this point, but... would it be less invasive
if instead of requiring the immedi
As discussed on -hackers, this patch allows the construction of an
empty array if an explicit cast to an array type is given (as in,
ARRAY[]::int[]).
postgres=# select array[]::int[];
array
---
{}
postgres=# select array[];
ERROR: no target type for empty array
HINT: Empty arrays must be
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
>> 1) How should we determine whether the array is multidimensional if we
>> know the type in advance?
> Well, given the array should be regular you should be able to just look
> at the first element, if it's a array look at it's first element, e
On Fri, Nov 30, 2007 at 06:13:20AM +1100, Brendan Jurd wrote:
> Hi folks,
>
> The patch is coming along nicely now. I do have a couple of questions
> about the implementation in transformArrayExpr though.
Awesome.
> 1) How should we determine whether the array is multidimensional if we
> know t
Hi folks,
The patch is coming along nicely now. I do have a couple of questions
about the implementation in transformArrayExpr though.
1) How should we determine whether the array is multidimensional if we
know the type in advance?
Currently, transformArrayExpr uses the results of its sear
Brendan Jurd escribió:
> If the only reason for keeping A_Const->typename around is the alleged
> code saving (as indicated by the code comments), my offer to do away
> with it is still on the table.
Code cleanup is always welcome.
--
Alvaro Herrera Developer, http://ww
On Nov 28, 2007 9:49 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> > I had a bit of a dig into this. A_Const->typename gets set directly
> > by the parse paths for "INTERVAL [(int)] string [interval range]". In
> > fact, as far as I can tell that's the _only_ place A_Const->typename
> > gets used at
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> I actually thought that A_ArrayExpr would be a good addition even if
> you ignore the matter of typecasting. It always seemed weird to me
> that the parser generates an ArrayExpr directly. ArrayExpr has a
> bunch of members that are only set by the tra
On Nov 28, 2007 4:19 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
> > Now I'm thinking I leave the grammar rules alone (apart from making it
> > legal to specify an empty list of elements), and instead push the
> > typename down into the child node from makeT
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> Now I'm thinking I leave the grammar rules alone (apart from making it
> legal to specify an empty list of elements), and instead push the
> typename down into the child node from makeTypeCast(), if the child is
> an A_ArrayExpr. Does that work better?
On Nov 28, 2007 2:56 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> > I wonder whether we are also interested in catching CAST(), e.g.:
>
> > CAST(ARRAY[] AS text[])
>
> I think you'll find that it's just about impossible to not handle both,
> because they look the same after the grammar gets done.
Tha
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> So far I've only considered the '::' cast syntax suggested in the
> original proposal, e.g.:
> ARRAY[]::text[]
> I wonder whether we are also interested in catching CAST(), e.g.:
> CAST(ARRAY[] AS text[])
I think you'll find that it's just about impo
So far I've only considered the '::' cast syntax suggested in the
original proposal, e.g.:
ARRAY[]::text[]
I wonder whether we are also interested in catching CAST(), e.g.:
CAST(ARRAY[] AS text[])
I'm personally okay with leaving it at support for '::', but
admittedly I am heavily biased toward
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> I'm not 100% clear on what the A_ prefix signifies ... is A_ArrayExpr
> a good name for the parse-time structure?
Yeah, might as well use that for consistency. The A_ doesn't seem
very meaningful to me either, but I don't want to rename the existing
ex
On Nov 27, 2007 8:04 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
> > ... So
> > unfortunately I can't just add a TypeName member to ArrayExpr.
>
> That would be quite the wrong thing to do anyway, since ArrayExpr is
> a run-time representation and shouldn't
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> This approach is making sense to me, but I've run into a bit of a
> dependency issue. A_Const does indeed have a slot for typecasts by
> way of a TypeName member. A_Const and TypeName are both defined in
> parsenodes.h, whereas ArrayExpr is defined in
Quoting Tom, from the previous thread linked by Martijn:
> 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
On Nov 26, 2007 3:58 AM, Martijn van Oosterhout <[EMAIL PROTECTED]> wrote:
> On Mon, Nov 26, 2007 at 03:51:37AM +1100, Brendan Jurd wrote:
> > I noticed in the 8.3 release notes that ARRAY(SELECT ...) now returns
> > an empty array if there are no rows returned by the subquery.
>
> This has come up
20 matches
Mail list logo
