Re: [GENERAL] Empty arrays with ARRAY[] - Mailing list pgsql-hackers

From Brendan Jurd
Subject Re: [GENERAL] Empty arrays with ARRAY[]
Date
Msg-id 37ed240d0803031915p6e58a075ycfb3f90b517bc468@mail.gmail.com
Whole thread Raw
In response to Re: [GENERAL] Empty arrays with ARRAY[]  ("Brendan Jurd" <direvus@gmail.com>)
Responses Re: [PATCHES] [GENERAL] Empty arrays with ARRAY[]  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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 again on Gregory's idea, and if that doesn't bear any
fruit I'd like to submit the patch as-is for review.

Regards,
BJ

On 01/12/2007, Brendan Jurd <direvus@gmail.com> wrote:
> On Nov 30, 2007 9:09 PM, Gregory Stark <stark@enterprisedb.com> 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 type".
>  > The only operation which would be allowed on it would be to cast it to some
>  > specific array type.
>  >
>  > That way things like
>  >
>  > UPDATE foo SET col = array[];
>  > INSERT INTO foo (col) VALUES (array[]);
>  >
>  > could be allowed if they could be contrived to introduce an assignment cast.
>
>  Not sure it would be less invasive, but I do like the outcome of being
>  able to create an empty array pending assignment.  In addition to your
>  examples, it might also make it possible to do things like this in
>  plpgsql
>
>  DECLARE
>   a text[] := array[];
>
>  Whereas my patch requires you to write
>
>   a text[]: =array[]::text[];
>
>  ... which seems pretty stupid.
>
...
>  Any suggestions about how you would enforce the "only allow casts to
>  array types" restriction on the empty array?
>

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: pg_dump additional options for performance
Next
From: "Joshua D. Drake"
Date:
Subject: Re: pg_dump additional options for performance