On Tue, Jul 2, 2024 at 3:19 PM jian he wrote:
> On Mon, Jul 1, 2024 at 6:45 PM Amit Langote wrote:
> >
> > On Sun, Jun 30, 2024 at 3:56 AM Tom Lane wrote:
> > > Alvaro Herrera writes:
> > > >> +/*
> > > >> + * For domains, consider the base type's typmod to decide whether
> > > >> to
On Mon, Jul 1, 2024 at 6:45 PM Amit Langote wrote:
>
> On Sun, Jun 30, 2024 at 3:56 AM Tom Lane wrote:
> > Alvaro Herrera writes:
> > >> +/*
> > >> + * For domains, consider the base type's typmod to decide whether
> > >> to setup
> > >> + * an implicit or explicit cast.
> > >> +
On Sun, Jun 30, 2024 at 3:56 AM Tom Lane wrote:
> Alvaro Herrera writes:
> >> +/*
> >> + * For domains, consider the base type's typmod to decide whether to
> >> setup
> >> + * an implicit or explicit cast.
> >> + */
> >> +if (get_typtype(returning->typid) == TYPTYPE_DOMAIN)
On Sun, Jun 30, 2024 at 2:24 AM Alvaro Herrera wrote:
>
> TBH I'm not super clear on why we decide on explicit or implicit cast
> based on presence of a typmod. Why isn't it better to always use an
> implicit one?
>
I am using an example to explain it.
SELECT JSON_SERIALIZE(JSON('{ "a" : 1 }
Alvaro Herrera writes:
>> +/*
>> + * For domains, consider the base type's typmod to decide whether to
>> setup
>> + * an implicit or explicit cast.
>> + */
>> +if (get_typtype(returning->typid) == TYPTYPE_DOMAIN)
>> +(void) getBaseTypeAndTypmod(returning->typid,
> diff --git a/src/backend/parser/parse_expr.c b/src/backend/parser/parse_expr.c
> index 233b7b1cc9..df766cdec1 100644
> --- a/src/backend/parser/parse_expr.c
> +++ b/src/backend/parser/parse_expr.c
> @@ -3583,6 +3583,7 @@ coerceJsonFuncExpr(ParseState *pstate, Node *expr,
> Node *res;
On Fri, Jun 28, 2024 at 3:14 PM jian he wrote:
> On Thu, Jun 27, 2024 at 7:48 PM Amit Langote wrote:
> > >
> > > I've attempted that in the attached 0001, which removes
> > > JsonExpr.coercion_expr and a bunch of code around it.
> > >
> > > 0002 is now the original patch minus the changes to
On Thu, Jun 27, 2024 at 7:48 PM Amit Langote wrote:
> >
> > I've attempted that in the attached 0001, which removes
> > JsonExpr.coercion_expr and a bunch of code around it.
> >
> > 0002 is now the original patch minus the changes to make
> > JSON_EXISTS(), JSON_QUERY(), and JSON_VALUE() behave
On Thu, Jun 27, 2024 at 6:57 PM Amit Langote wrote:
> On Wed, Jun 26, 2024 at 11:46 PM jian he wrote:
> > On Wed, Jun 26, 2024 at 8:39 PM Amit Langote
> > wrote:
> > >
> > > >
> > > > The RETURNING variant giving an error is what the standard asks us to
> > > > do apparently. I read Tom's
Hi,
On Wed, Jun 26, 2024 at 11:46 PM jian he wrote:
> On Wed, Jun 26, 2024 at 8:39 PM Amit Langote wrote:
> >
> > >
> > > The RETURNING variant giving an error is what the standard asks us to
> > > do apparently. I read Tom's last message on this thread as agreeing
> > > to that, even though
hi.
I have assembled a list of simple examples, some works (for comparison
sake), most not work
as intended.
CREATE DOMAIN queryfuncs_char2 AS char(2) CHECK (VALUE NOT IN ('12'));
CREATE DOMAIN queryfuncs_d_interval AS interval(2) CHECK (VALUE is not null);
SELECT JSON_VALUE(jsonb '111', '$'
On Wed, Jun 26, 2024 at 8:39 PM Amit Langote wrote:
>
> >
> > The RETURNING variant giving an error is what the standard asks us to
> > do apparently. I read Tom's last message on this thread as agreeing
> > to that, even though hesitantly. He can correct me if I got that
> > wrong.
> >
> > >
On Fri, Jun 21, 2024 at 10:48 PM Amit Langote wrote:
> On Fri, Jun 21, 2024 at 4:05 PM jian he wrote:
> > hi.
> > i am a little confused.
> >
> > here[1] tom says:
> > > Yeah, I too think this is a cast, and truncation is the spec-defined
> > > behavior for casting to varchar with a specific
Hi,
Thanks for taking a look.
On Fri, Jun 21, 2024 at 4:05 PM jian he wrote:
> On Tue, Jun 18, 2024 at 5:02 PM Amit Langote wrote:
> > On Tue, Jun 4, 2024 at 7:03 PM Amit Langote wrote:
> > > On Tue, Jun 4, 2024 at 2:20 AM Tom Lane wrote:
> > > > Peter Eisentraut writes:
> > > > > On
On Tue, Jun 18, 2024 at 5:02 PM Amit Langote wrote:
>
> On Tue, Jun 4, 2024 at 7:03 PM Amit Langote wrote:
> > On Tue, Jun 4, 2024 at 2:20 AM Tom Lane wrote:
> > > Peter Eisentraut writes:
> > > > On 02.06.24 21:46, Tom Lane wrote:
> > > >> If you don't
> > > >> like our current behavior, then
On Tue, Jun 4, 2024 at 7:03 PM Amit Langote wrote:
> On Tue, Jun 4, 2024 at 2:20 AM Tom Lane wrote:
> > Peter Eisentraut writes:
> > > On 02.06.24 21:46, Tom Lane wrote:
> > >> If you don't
> > >> like our current behavior, then either you have to say that RETURNING
> > >> with a length-limited
On Tue, Jun 4, 2024 at 2:20 AM Tom Lane wrote:
> Peter Eisentraut writes:
> > On 02.06.24 21:46, Tom Lane wrote:
> >> If you don't
> >> like our current behavior, then either you have to say that RETURNING
> >> with a length-limited target type is illegal (which is problematic
> >> for the spec,
Peter Eisentraut writes:
> On 02.06.24 21:46, Tom Lane wrote:
>> If you don't
>> like our current behavior, then either you have to say that RETURNING
>> with a length-limited target type is illegal (which is problematic
>> for the spec, since they have no such type) or that the cast behaves
>>
On 02.06.24 21:46, Tom Lane wrote:
If you don't
like our current behavior, then either you have to say that RETURNING
with a length-limited target type is illegal (which is problematic
for the spec, since they have no such type) or that the cast behaves
like an implicit cast, with errors for
Peter Eisentraut writes:
> On 29.05.24 18:44, Tom Lane wrote:
>> Yeah, I too think this is a cast, and truncation is the spec-defined
>> behavior for casting to varchar with a specific length limit.
> The SQL standard says essentially that the output of json_serialize() is
> some string that
On 29.05.24 18:44, Tom Lane wrote:
Amit Langote writes:
On Mon, May 27, 2024 at 7:10 PM Alvaro Herrera wrote:
On 2024-May-27, Alvaro Herrera wrote:
I just noticed this behavior, which looks like a bug to me:
select json_serialize('{"a":1, "a":2}' returning varchar(5));
json_serialize
Amit Langote writes:
> On Mon, May 27, 2024 at 7:10 PM Alvaro Herrera
> wrote:
>> On 2024-May-27, Alvaro Herrera wrote:
>> I just noticed this behavior, which looks like a bug to me:
>>
>> select json_serialize('{"a":1, "a":2}' returning varchar(5));
>> json_serialize
>>
>>
Hi Alvaro,
On Mon, May 27, 2024 at 7:10 PM Alvaro Herrera wrote:
>
> On 2024-May-27, Alvaro Herrera wrote:
>
> > > JSON_SERIALIZE()
>
> I just noticed this behavior, which looks like a bug to me:
>
> select json_serialize('{"a":1, "a":2}' returning varchar(5));
> json_serialize
>
On Monday, May 27, 2024, Alvaro Herrera wrote:
> On 2024-May-27, Alvaro Herrera wrote:
>
> > > JSON_SERIALIZE()
>
> I just noticed this behavior, which looks like a bug to me:
>
> select json_serialize('{"a":1, "a":2}' returning varchar(5));
> json_serialize
>
> {"a":
>
> I
On 2024-May-27, Alvaro Herrera wrote:
> > JSON_SERIALIZE()
I just noticed this behavior, which looks like a bug to me:
select json_serialize('{"a":1, "a":2}' returning varchar(5));
json_serialize
{"a":
I think this function should throw an error if the destination type
25 matches
Mail list logo
