Re: proposal - function string_to_table

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: proposal - function string_to_table
Дата
Msg-id CAFj8pRDTG8NvUQRn2M7ByK6BhrmJL81B-OOw3QmV_7WGgTLo5w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: proposal - function string_to_table  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: proposal - function string_to_table  (Peter Smith <smithpb2250@gmail.com>)
Список pgsql-hackers


ne 5. 7. 2020 v 13:30 odesílatel Pavel Stehule <pavel.stehule@gmail.com> napsal:


pá 5. 6. 2020 v 13:55 odesílatel Pavel Stehule <pavel.stehule@gmail.com> napsal:
Hi

čt 4. 6. 2020 v 11:49 odesílatel movead.li@highgo.ca <movead.li@highgo.ca> napsal:
+{ oid => '2228', descr => 'split delimited text',
+  proname => 'string_to_table', prorows => '1000', proretset => 't',
+  prorettype => 'text', proargtypes => 'text text',
+  prosrc => 'text_to_table' },
+{ oid => '2282', descr => 'split delimited text with null string',
+  proname => 'string_to_table', prorows => '1000', proretset => 't',
+  prorettype => 'text', proargtypes => 'text text text',
+  prosrc => 'text_to_table_null' },

I go through the patch, and everything looks good to me. But I do not know
why it needs a 'text_to_table_null()', it's ok to put a 'text_to_table' there, I think.

It is a convention in Postgres - every SQL unique signature has its own unique internal C function.

I am sending a refreshed patch.

rebase

two fresh fix

a) remove garbage from patch that breaks doc

b) these functions should not be strict - be consistent with string_to_array functions

Regards

Pavel
 

Regards

Pavel


Regards

Pavel






Regards,
Highgo Software (Canada/China/Pakistan)
URL : www.highgo.ca
EMAIL: mailto:movead(dot)li(at)highgo(dot)ca
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Justin Pryzby
Дата:
Сообщение: "tuple concurrently updated" in pg_restore --jobs
Следующее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: archive status ".ready" files may be created too early