>> 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@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.