2018-07-16 15:22 GMT+02:00 Dmitry Igrishin <dmit...@gmail.com>: > > > пн, 16 июл. 2018 г. в 16:00, Pavel Stehule <pavel.steh...@gmail.com>: > >> >> >> 2018-07-16 14:28 GMT+02:00 Dmitry Igrishin <dmit...@gmail.com>: >> >>> >>> >>> пн, 16 июл. 2018 г. в 15:01, Pavel Stehule <pavel.steh...@gmail.com>: >>> >>>> >>>> >>>> 2018-07-16 13:52 GMT+02:00 Dmitry Igrishin <dmit...@gmail.com>: >>>> >>>>> >>>>> >>>>> пн, 16 июл. 2018 г. в 14:26, <kpi6...@gmail.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.) >
The opinions about VSC are good, but I don't use it and my opinions and experience are zero. Pavel
