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

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

2018-07-16 14:28 GMT+02:00 Dmitry Igrishin <dmitigr@gmail.com>:

пн, 16 июл. 2018 г. в 15:01, Pavel Stehule <pavel.stehule@gmail.com>:

2018-07-16 13:52 GMT+02:00 Dmitry Igrishin <dmitigr@gmail.com>:

пн, 16 июл. 2018 г. в 14:26, <kpi6288@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.)