Re: Large expressions in indexes can't be stored (non-TOASTable)
В списке pgsql-hackers по дате отправления:
| От | Nathan Bossart |
|---|---|
| Тема | Re: Large expressions in indexes can't be stored (non-TOASTable) |
| Дата | |
| Msg-id | aAla1fg-1vPeXNck@nathan обсуждение исходный текст |
| Ответ на | Re: Large expressions in indexes can't be stored (non-TOASTable) (Nathan Bossart <nathandbossart@gmail.com>) |
| Ответы |
Re: Large expressions in indexes can't be stored (non-TOASTable)
|
| Список | pgsql-hackers |
On Tue, Apr 22, 2025 at 12:21:01PM -0500, Nathan Bossart wrote: > On Tue, Apr 22, 2025 at 05:17:17PM +0530, Nisha Moond wrote: >> 5) As Euler pointed out, logical replication already has a built-in >> restriction for internally assigned origin names, limiting them to >> NAMEDATALEN. Given that, only the SQL function >> pg_replication_origin_create() is capable of creating longer origin >> names. Would it make sense to consider moving the check into >> pg_replication_origin_create() itself, since it seems redundant for >> all other callers? >> That said, if there's a possibility of future callers needing this >> restriction at a lower level, it may be reasonable to leave it as is. > > pg_replication_origin_create() might be a better place. After all, that's > where we're enforcing the name doesn't start with "pg_" and, for testing, > _does_ start with "regress_". Plus, it seems highly unlikely that any > other callers of replorigin_create() will ever provide names longer than > 512 bytes. Here is a new version of the patch with this change. -- nathan
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера