Re: proposal - function string_to_table

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Peter Smith <smithpb2250(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-25 06:57:27
Message-ID: CAFj8pRCgMkRUeD2PyGkJzgsGugacuM_sDD+Dpf4mE6Adu=6+6A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

út 25. 8. 2020 v 1:19 odesílatel Peter Smith <smithpb2250(at)gmail(dot)com> napsal:

> Hi.
>
> I have re-checked the string_to_table_20200824.patch.
>
> ====
>
> On Tue, Aug 25, 2020 at 2:34 AM Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
>
> >> 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"
> >
> >
> > fixed
> >
>
> No. You wrote "separate row of table". Should say "separate row of the
> table".
>

should be fixed now

> ====
>
> QUESTION (pg_proc.dat)
>
> I noticed the oids of the functions are modified in this latest patch.
> They seem 1000's away from the next nearest oid.
> I was curious about the reason for those particular numbers (8432, 8433)?
>

When you run ./unused_oids script, then you get this message

[pavel(at)nemesis catalog]$ ./unused_oids
4 - 9
560 - 583
786 - 789
811 - 816
1136 - 1137
2121
2137
2228
3435
3585
4035
4142
4179 - 4180
4198 - 4199
4225 - 4301
4388 - 4401
4450 - 4451
4532 - 4565
4572 - 4999
5097 - 5999
6015 - 6099
6105
6107 - 6109
6116
6122 - 8431
8434 - 8455
8457 - 9999
Patches should use a more-or-less consecutive range of OIDs.
Best practice is to start with a random choice in the range 8000-9999.
Suggested random unused OID: 8973 (1027 consecutive OID(s) available
starting here)

For me, this is simple protection against oid collision under development,
and I expect so commiters does oid' space defragmentation.

Regards

Pavel

> ====
>
> Kind Regards,
> Peter Smith.
> Fujitsu Australia
>

Attachment Content-Type Size
string_to_table-20200825.patch text/x-patch 37.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Li Japin 2020-08-25 07:28:41 Re: file_fdw vs relative paths
Previous Message Kyotaro Horiguchi 2020-08-25 06:53:20 Re: "cert" + clientcert=verify-ca in pg_hba.conf?