Re: GSoC 2015 Idea Discussion

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: GSoC 2015 Idea Discussion
Дата
Msg-id 4450.1426601614@sss.pgh.pa.us
обсуждение исходный текст
Ответ на GSoC 2015 Idea Discussion  (Jackson Isaac <jacksonisaac2008@gmail.com>)
Список pgsql-hackers
Jackson Isaac <jacksonisaac2008@gmail.com> writes:
> I was looking at the proposal ideas at
> https://wiki.postgresql.org/wiki/GSoC_2015 and was very much
> interested in the idea 'PL/PgSQL x++; x+= 2; operators'.

Hm.  I don't think that idea has been discussed on-list at all (or maybe
it has but I missed it).  I'm not too excited about the ++ aspect of it
because that would require plpgsql to invent semantics out of whole
cloth, and it's hard to see how to do it in any respectably
datatype-independent way.  But you could imagine transforming
"x += y" into "x := x + (y)", for any arbitrary operator +, without
making any datatype-dependent assumptions.

I'm not entirely sure how to make that work syntactically though ---
there are lots of operator names that end with "=", so you would have
difficulty deciding when it was OK to split that operator token apart.

Another problem is that commit bb1b8f694ad2efc35ebae2acfa2c18a2197b82a1
added an assumption that the second token of an assignment would be
exactly := (or its alias =).  I doubt it'd be all right to extend that
to say "any operator ending in "=" is assumed not to be possible as the
second token of a non-assignment statement".  We don't currently have
any prefix operators whose names end in "=", so the rule would work today,
but that seems like kind of a nasty restriction.

It would be easier to solve these problems with a variant syntax, likex + := y
but that gives up a lot of the attractiveness of the idea :-(

I'm kind of interested in this if anyone can think of a way around the
syntactic difficulties, because it would tie nicely into the rough
ideas I had in
http://www.postgresql.org/message-id/20178.1423598435@sss.pgh.pa.us
about allowing extension datatypes to participate in optimized
update-in-place assignments.  We could legislate that you only get the
performance benefit of an in-place update if you invoke it with this
new syntax; that would make it a lot easier to identify when to pass
a R/W pointer to a function.
        regards, tom lane



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

Предыдущее
От: Kouhei Kaigai
Дата:
Сообщение: Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Precedence of standard comparison operators