Re: proposal - function string_to_table

From: Peter Smith <smithpb2250(at)gmail(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: "movead(dot)li(at)highgo(dot)ca" <movead(dot)li(at)highgo(dot)ca>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal - function string_to_table
Date: 2020-08-24 02:18:33
Message-ID: CAHut+Pv5ABmKY0RuSbR7GGt4YoXJvSRkZZW1kE4TWSu-Bd=KSg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I have re-checked the string_to_table_20200821.patch.

Below is one remaining problem.

====

COMMENT (help text)

+ Splits the <parameter>string</parameter> at occurrences
+ of <parameter>delimiter</parameter> and forms the remaining data
+ into a table with one <type>text</type> type column.
+ If <parameter>delimiter</parameter> is <literal>NULL</literal>,
+ each character in the <parameter>string</parameter> will become a
+ separate element in the array.

Seems like here is a cut/paste error from the string_to_array help text.

"separate element in the array" should say "separate row of the table"

====

>>> Maybe a different choice of function name would be more consistent
>>> with what is already there?
>>> e.g. split_to_table, string_split_to_table, etc.
>>
>> I don't agree. This function is twin (with almost identical behaviour) for "string_to_array" function, so I think so the name is correct.

OK

====

Kind Regards,
Peter Smith.
Fujitsu Australia

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-08-24 02:53:18 Continuing instability in insert-conflict-specconflict test
Previous Message Tom Lane 2020-08-23 21:08:16 Re: Row estimates for empty tables