Re: [HACKERS] Description of create_singleton_array() - Mailing list pgsql-hackers

From Neha Khatri
Subject Re: [HACKERS] Description of create_singleton_array()
Date
Msg-id CAFO0U+8+i63VqKW8=aypkyG0hsGWbz2a0+HHq=D7Jy-YfrYWyQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Description of create_singleton_array()  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, May 2, 2017 at 5:47 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:


Well, now that we've been burnt once by the specific call site moving,
I think we should learn from experience and not have this say where
it's called from.  That's a lousy substitute for defining the API
expectations explicitly, anyway.
 
Agreed. 

Your proposed patch tries to improve that, but the result isn't
necessarily a "1-D array" --- it's a one-element array, with possibly
a higher number of dimensions than 1.  (Not really sure why we thought
flexibility in the number of dimensions was useful, but there it is.)
 
Ah, yes. The function in itself has the capability to allow m-D array where 'm' could be more than 1. I kind of missed this fact because the only caller of the function, attempts to create a 1-D array. 

I wonder if we wouldn't be better off to get rid of this function entirely.
It seems like it's not providing any real increment of simplicity over a
direct call to construct_md_array, since text_to_array could perfectly
well hard-wire the array element storage properties, as we do in very many
other places.  And it's a bug waiting to happen, looks like.

Yesterday, while prying into the definition of this function it did occur to me that whether there is an additional benefit of this function over construct_md_array. Yes, it looked like that construct_md_array could be used in lieu of create_singleton_array. 

Regards,
Neha

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: [HACKERS] pg_dump emits ALTER TABLE ONLY partitioned_table
Next
From: Peter Geoghegan
Date:
Subject: Re: [HACKERS] A design for amcheck heapam verification