Re: [HACKERS] [PATCH] Generic type subscripting

Поиск
Список
Период
Сортировка
От Chapman Flack
Тема Re: [HACKERS] [PATCH] Generic type subscripting
Дата
Msg-id 5FDBBAE4.2020501@anastigmatix.net
обсуждение исходный текст
Ответ на Re: [HACKERS] [PATCH] Generic type subscripting  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] [PATCH] Generic type subscripting  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 12/17/20 14:28, Tom Lane wrote:
> Pavel Stehule <pavel.stehule@gmail.com> writes:
>>   n int;
>>   v varchar;
>>   js jsonb default '{"n": 100, "v" : "Hello"};
>> BEGIN
>>   n := js['n'];
>>   v := js['v'];
> 
> If you're imagining that js['n'] and js['v'] would emit different
> datatypes, forget it.  That would require knowing at parse time
> what the structure of the json object will be at run time.

Would it be feasible to analyze that as something like an implicit
'treat as' with the type of the assignment target?

'treat as' is an operator in XML Query that's distinct from 'cast as';
'cast as foo' has ordinary cast semantics and can coerce non-foo to foo;
'treat as foo' is just a promise from the programmer: "go ahead and
statically rely on this being a foo, and give me a runtime exception
if it isn't".

It would offer a nice economy of expression.

Following that idea further, if there were such a thing as a 'treat as'
node, would the implicit generation of such a node, according to an
assignment target data type, be the kind of thing that could be accomplished
by a user function's planner-support function?

Regards,
-Chap



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

Предыдущее
От: Dmitry Dolgov
Дата:
Сообщение: Re: [HACKERS] [PATCH] Generic type subscripting
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: [HACKERS] [PATCH] Generic type subscripting