Re: SYSTEM_USER reserved word implementation
От | Michael Paquier |
---|---|
Тема | Re: SYSTEM_USER reserved word implementation |
Дата | |
Msg-id | YzO/PawKtWSvLGFC@paquier.xyz обсуждение исходный текст |
Ответ на | Re: SYSTEM_USER reserved word implementation (Jacob Champion <jchampion@timescale.com>) |
Ответы |
Re: SYSTEM_USER reserved word implementation
|
Список | pgsql-hackers |
On Tue, Sep 27, 2022 at 03:38:49PM -0700, Jacob Champion wrote: > On 9/26/22 06:29, Drouvot, Bertrand wrote: > Since there are only internal clients to the API, I'd argue this makes > more sense as an Assert(authn_id != NULL), but I don't think it's a > dealbreaker. Using an assert() looks like a good idea from here. If this is called with a NULL authn, this could reflect a problem in the authentication logic. >> As far the assertion failure mentioned by Michael when moving the >> SVFOP_SYSTEM_USER from NAMEOID to TEXTOID: V4 is assuming that it is >> safe to force the collation to C_COLLATION_OID for SQLValueFunction >> having a TEXT type, but I would be happy to also hear your thoughts >> about it. > > Unfortunately I don't have much to add here; I don't know enough about > the underlying problems. I have been looking at that, and after putting my hands on that this comes down to the facility introduced in 40c24bf. So, I think that we'd better use COERCE_SQL_SYNTAX so as there is no need to worry about the shortcuts this patch is trying to use with the collation setup. And there are a few tests for get_func_sql_syntax() in create_view.sql. Note that this makes the patch slightly shorter, and simpler. The docs still mentioned "name", and not "text". This brings in a second point. 40c24bf has refrained from removing SQLValueFunction, but based the experience on this thread I see a pretty good argument in doing the jump once and for all. This deserves a separate discussion, though. I'll do that and create a new thread. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: