Re: GSoC proposal for pgAdmin 4 bytea support

Dear PostgreSQL community,

I have submitted a proposal for the project pgAdmin 4 bytea support. I
appreciate your comments and feedback. Thank you!

https://docs.google.com/document/d/1ADkdj1Nnhzpy1HTqgs6c6nVPXvPBmwLaysmaNX9eFc0/edit?usp=sharing

Howard

On Wed, Mar 20, 2019 at 8:26 AM Haoran Yu <haleyyew(at)gmail(dot)com> wrote:

> Thanks Dave! I looked at your project descriptions and decided to create
> an application for Query Tool Graphing. Here's my partially complete
> proposal:
>
> https://docs.google.com/document/d/1zZhpmZQZBuZNsJA1UeKHrXKFJQCfmKKvTsnNbdmtT_0/edit?usp=sharing
>
> Everyone's welcome to give me feedback/suggestions! Thank you!
>
> Howard
>
> On Mon, Mar 4, 2019 at 3:15 AM Dave Page <dpage(at)pgadmin(dot)org> wrote:
>
>> Hi
>>
>> [Moving pgsql-hackers to BCC to prevent further cross-posting]
>>
>> On Sat, Mar 2, 2019 at 12:36 AM Haoran Yu <haleyyew(at)gmail(dot)com> wrote:
>>
>>> Dear PostgreSQL community:
>>>
>>> I am a MSc student in computer science working on data management
>>> research, and I will likely graduate this summer. I also was a participant
>>> of GSoC in 2017 working with the NRNB organization on data standards
>>> conversion.
>>>
>>
>> Cool.
>>
>>
>>>
>>> I have been a user of pgAdmin 4 briefly, and I am interested in learning
>>> more about the project and contribute to it. The projects web page lists 3
>>> potential projects, but I don't know which one I'm suitable for. Are there
>>> any suggestions on how to get started on exploring more about the Query
>>> Tool in pgAdmin? For example, use cases with some sample data would be
>>> nice! I also checked out the pgadmin4 repository from git, and I'll start
>>> exploring the code shortly.
>>>
>>
>> The choice of which project to work on is entirely down to your own
>> personal interests. You can even propose something else if you like, though
>> the listed projects are ones that are likely to be accepted as they're
>> known to be valuable.
>>
>> The first project (Query Tool Graphing) has a simple use case of allowing
>> any user to quickly render a graph of their data. More specific use cases
>> can be discussed as part of the project, but quite simply the idea is to
>> allow users a quick and easy way to visualise their data. It would probably
>> help to install PostGIS in a database, and then load the test data we used
>> to play with it and see how that works (see
>> https://www.postgresql.org/message-id/CAA7HE_cU7bmQv1kdPB3hiKYGJLaOVVft_XxqcD6ueJpAGfqykQ%40mail.gmail.com
>> - specifically, the Google Drive link). The GIS viewer is similar to what I
>> have in mind for this feature, except that instead of drawing maps, we'd
>> draw different types of graphs.
>>
>> The second project is about supporting bytea in the Query Tool. Right now
>> bytea data isn't rendered when you run a query - we show a placeholder
>> instead. The use case here is for users that store media files in bytea
>> columns; we want to be able to automatically detect different file types
>> and allow them to be viewed (or listened to) in the tool. When running in
>> Edit more, the user should be able to add or replace data in a row by
>> uploading from the browser. I don't have any sample data for this.
>>
>> The final project listed is a long-term design goal of pgAdmin 4 (and
>> probably the hardest project). In pgAdmin 3 we had separate Query Tool and
>> View/Edit data tools. In pgAdmin 4, we made them into the same tool, but
>> running in two separate modes. The use case here is to prevent the need for
>> the user to choose what mode to open the tool in (Query Tool vs. View/Edit
>> Data), and to automatically detect whether any query would produce an
>> updateable resultset. This would allow the tool to offer all features at
>> all times, and simple enable/disable in-place editing of the query results
>> if there's no way to automatically generate an update/insert/delete
>> statement. This one is potentially hard as it will likely require some
>> amount of parsing of the query string to make that determination. You can
>> simply play with any test data to get a feel for this one.
>>
>> Hope this helps.
>>
>> Regards, Dave.
>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>