Re: Document DateStyle effect on jsonpath string()

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Document DateStyle effect on jsonpath string()
Дата
Msg-id 5e8879d0-a3c8-4be2-950f-d83aa2af953a@eisentraut.org
обсуждение исходный текст
Ответ на Re: Document DateStyle effect on jsonpath string()  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Document DateStyle effect on jsonpath string()
Список pgsql-hackers
On 10.09.24 22:16, Tom Lane wrote:
> Peter Eisentraut <peter@eisentraut.org> writes:
>> These JSON path functions are specified by the SQL standard, so they
>> shouldn't depend on PostgreSQL-specific settings.  At least in new
>> functionality we should avoid that, no?
> 
> Hmm ... but does the standard precisely define the output format?
> 
> Since these conversions are built on our own timestamp I/O code,
> I rather imagine there is quite a lot of behavior there that's
> not to be found in the standard.  That doesn't really trouble
> me as long as the spec's behavior is a subset of it (i.e.,
> reachable as long as you've got the right parameter settings).

Actually, the standard prohibits this call:

"""
XV) If JM specifies string, then:

1) Forallj,1(one)≤j≤n,
Case:

a) If Ij is not a character string, number, or Boolean value,
then let ST be data exception — non-string SQL/JSON item (2202X).

b) Otherwise, let X be an SQL variable whose value is Ij. Let ML be an 
implementation-defined (IL006) maximum
length of variable-length character strings. Let Vj be the result of

CAST (X AS CHARACTER VARYING(ML)

If this conversion results in an exception condition, then
let ST be that exception condition.
"""

So I guess we have extended this and the current behavior is consistent 
with item b).

What I'm concerned about is that this makes the behavior of JSON_QUERY 
non-immutable.  Maybe there are other reasons for it to be 
non-immutable, in which case this isn't important.  But it might be 
worth avoiding that?




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