пн, 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.)
