Re: Do we need yet another IDE (SQL development assistant) for PostgreSQL?

пн, 16 июл. 2018 г. в 16:00, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:

>
>
> 2018-07-16 14:28 GMT+02:00 Dmitry Igrishin <dmitigr(at)gmail(dot)com>:
>
>>
>>
>> пн, 16 июл. 2018 г. в 15:01, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:
>>
>>>
>>>
>>> 2018-07-16 13:52 GMT+02:00 Dmitry Igrishin <dmitigr(at)gmail(dot)com>:
>>>
>>>>
>>>>
>>>> пн, 16 июл. 2018 г. в 14:26, <kpi6288(at)gmail(dot)com>:
>>>>
>>>>> We – and the majority of our customers - are mainly focused on
>>>>> Windows. We use pgadmin iii and our own assistants. pgadmin iv ist still
>>>>> too slow on Windows compared to pgadmin iii. That is one reason why we
>>>>> still use PostgreSQL 9.6.
>>>>>
>>>> For performance reasons I mostly use the C++ language. Thus, I think
>>>> the performance
>>>> should not be a problem here.
>>>>
>>>>
>>>>>
>>>>>
>>>>> That said, one requirement on a commercial tool for us would be
>>>>> royalty free distribution to our customers. It should however provide the
>>>>> functions of pgadmin iii.
>>>>>
>>>> Do you need an administration tool or an assistant for database
>>>> development? I conceived Pgspa as a
>>>> development tool, which works with source files organized in the usual
>>>> way. For example, the sources
>>>> of the schema "foo" could be organized as:
>>>> foo/functions/*.sql
>>>> /views/*.sql
>>>> /triggers/*.sql
>>>> ...
>>>> The developer works with files rather than objects retrieved from the
>>>> database and loaded
>>>> into the tree view of the GUI (like in pgAdmin and most of other
>>>> similar tools). Though, the
>>>> database browser GUI is a useful feature of course, and should be
>>>> implemented.
>>>>
>>>
>>> Few years I am thinking about new IDE for stored procedures. Probably It
>>> should not be written from scratch, but It should to be multiplatform.
>>>
>> Me too :-) I have a command line prototype of the tool with the basic
>> functional. It's written
>> in C++ by using the Pgfe client library and in PL/pgSQL as the PostgreSQL
>> extension.
>>
>>
>>> what can be nice
>>>
>>> 1. source should be in files with GIT support
>>>
>> +1. It's the main feature. Already done.
>>
>>> 2. integration with developer databese + well autocomplete support
>>>
>> It's the most hard part and could be implemented later.
>>
>
> The basic autocomplete is necessary - table names, column names, .. It
> should not be too intelligent - but this is main benefit again generic
> already available IDE.
>
Suppose the one write
create table foo (id integer default n
and the autocomplete shows all it knows that starts with "n". Would you be
satisfied with such an autocomplete? :-)
Me - not. (Although it is relatively easy to implement.)

>
>
>> 3. formatting - SQL, PL, ..
>>>
>> Good feature for future releases.
>>
> 4. online code validation
>>>
>> Not sure I understand. Can you please elaborate what do you mean?
>>
>
> For PLpgSQL simple (press one key) send source code to server and
> highlight errors (it can be integrated with plpgsql_check). For SQL using
> not existing identifier, ..
>
Wow, cool! With plpgsql_check it's possible to achieve the user experience
similar to the SLIME - the IDE for Common Lisp.

>
>
>
>> 5. The should not be strong relation between files and schemas. Now is
>>> not too hard to have information what content is in some file. There can be
>>> physical organization (by files), and logical (by schemas, functions,
>>> views, ...)
>>>
>> I agree and there is no problems with it. But logical organization would
>> be a bit simpler
>> to implement, and would be suitable for the most users. Also it can be
>> even helpful when someone
>> working with foreign project since the database objects are arranged in
>> shelves.
>>
>
> I cannot to estimate the cost of these variants - I use mapping - one
> schema - one or more files, but the objects to files are divided by
> dependency - some objects can be simply updated, other not.
>
The prototype I already have can deal with DDL commands organized as the
user wish. No
need to create the objects in the order of dependency. This is a very
convenient.

>
> Very specific kind of DB objects are views. The IDE can helps with changes
> of views. It is pretty hard now due dependency.
>
Yes! My tool can safely drop the dependend objects (with no cascading) and
recreate all of them from files.

>
>
>> 6. good performance is important - but Java is good enough today -
>>> DBeaver is has good speed
>>>
>> My primary (and favorite) language still C++ :-)
>>
>
> I have no problem with it. But C++ is harder for junior developers and
> multiplatform Qt can be expensive for commercial product. But I understand
> personal preferences (I don't like Java too). On second hand - the
> performance argument is not valid against Java.
>

>
>>> Regards
>>>
>>> Good luck - can be pretty hard to write it.
>>>
>> Thank you, Pavel! But I haven't decided about starting this project,
>> since I'm not sure about
>> the interest from the community.
>>
>
> Understand. Developer is alone every time. But lot of work is done. If I
> started similar project (but I have not this plan), then I don't try to
> write own IDE, but I'll use some existing and I'll write plugin for
> eclipse, or some else.
>
What do you think about Visual Studio Code? It's would be fun to write a
plugin that
call the command line tool implemented in C++. (Actually, I use Emacs and
run my tool in
the *compilation* buffer. More than enough for me.)