Обсуждение: GSoC 2015 Idea Discussion

Поиск
Список
Период
Сортировка

GSoC 2015 Idea Discussion

От
Jackson Isaac
Дата:
Hi,

I am Jackson Isaac pursuing 3rd Year B.Tech Computer Science and
Engineering at Amrita Vishwa Vidyapeetham, India.

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'.

I have been using postgres since 1 year and I had thought about the
same idea while working on functions and triggers, and hoped to do a
project on that (luckily it is proposed too as a GSoC project :) ). I
would like to know more about the idea and start working on the
project proposal too.

Can anyone please tell me who is mentoring this project who can guide
me on the right path. I am willing to read tutorials and other
materials needed to go on with this project.

Thank You,
Jackson Isaac
S6 B.Tech CSE
Amrita Vishwa Vidyapeetham
jacksonisaac.wordpress.com
Github/JacksonIsaac



Re: GSoC 2015 Idea Discussion

От
Tom Lane
Дата:
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