Обсуждение: Ways to improve PgAdmin III SQL context help

Поиск
Список
Период
Сортировка

Ways to improve PgAdmin III SQL context help

От
"J.F. Oster"
Дата:
Hello All!

Currently when I press F1 in the SQL Query window, PgAdmin III looks
for first token of selected (or whole) text, recognizes most of SQL
commands and tries to open corresponding help page.

I tried to extend that list with data types, functions, system
catalogs&views etc:
https://github.com/jinfroster/pgadmin3/commit/6e70b9f2252ec22e22c4188d5cfe0cf18e6ce7a2
Yeah, quite a stupid way :) but after a week of testing it
(writing queries and pl/pgsql), I have a positively pleasant
experience, even that is really helpful!

Which way is better? IMO it is reasonable to index whole Postgre's
actual doc/src/sgml/*.sgml in a separate PgAdmin's build target and
bundle fresh index file with every release of PgAdmin.
Branded distributions could use same workflow if their documentation
inherits same SGML.
Index file should contain:
 - Keywords to be searched, collected from several DocBook tags like
 <term>, <indexterm>, <acronym> etc - about 15 of them are most
 informative.
 - Locations (Page, Anchor, Title), collected from <sect1>, <chapter>
 etc.
 - Weights (keyword K in location L has weigth W).
   W(K,L) = sum(Nklt * Wt), where
    Nklt is number of occurences of keyword K in location L in tag T
    Wt is weight for tag T (say, <indexterm> is 10000, but
    <literal> is 1 etc).

So a user can get most relevant Page#Anchor instantly for a word under
cursor, or a sorted list of pages to choose from (Title will be useful
here).

Currently my questions are:
1. Is such development interesting to the community?
2. Is supposed workflow for index bundling acceptable?
3. May be, some ready-made open source solution can be used for
indexing DocBook SGML and later searching? It's searching engine is to
be incorporated into PgAdmin.

I'd like to work on subject and look for any constructive opinions.
Thanks!

--
Best regards,
 J.F.



Re: [pgadmin-hackers] Ways to improve PgAdmin III SQL context help

От
Dave Page
Дата:
Hi

On Tue, Feb 11, 2014 at 5:33 PM, J.F. Oster <jinfroster@mail.ru> wrote:
> Hello All!
>
> Currently when I press F1 in the SQL Query window, PgAdmin III looks
> for first token of selected (or whole) text, recognizes most of SQL
> commands and tries to open corresponding help page.
>
> I tried to extend that list with data types, functions, system
> catalogs&views etc:
> https://github.com/jinfroster/pgadmin3/commit/6e70b9f2252ec22e22c4188d5cfe0cf18e6ce7a2
> Yeah, quite a stupid way :) but after a week of testing it
> (writing queries and pl/pgsql), I have a positively pleasant
> experience, even that is really helpful!

I can see that would be useful.

> Which way is better? IMO it is reasonable to index whole Postgre's
> actual doc/src/sgml/*.sgml in a separate PgAdmin's build target and
> bundle fresh index file with every release of PgAdmin.
> Branded distributions could use same workflow if their documentation
> inherits same SGML.
> Index file should contain:
>  - Keywords to be searched, collected from several DocBook tags like
>  <term>, <indexterm>, <acronym> etc - about 15 of them are most
>  informative.
>  - Locations (Page, Anchor, Title), collected from <sect1>, <chapter>
>  etc.
>  - Weights (keyword K in location L has weigth W).
>    W(K,L) = sum(Nklt * Wt), where
>     Nklt is number of occurences of keyword K in location L in tag T
>     Wt is weight for tag T (say, <indexterm> is 10000, but
>     <literal> is 1 etc).
>
> So a user can get most relevant Page#Anchor instantly for a word under
> cursor, or a sorted list of pages to choose from (Title will be useful
> here).
>
> Currently my questions are:
> 1. Is such development interesting to the community?

I have no objection to extending the capabilities in general.

> 2. Is supposed workflow for index bundling acceptable?

However, I'm really not keen on this idea for a couple of reasons:

1) We used to include the PostgreSQL documentation with pgAdmin, and
it was a *real* pain to maintain. We got rid of it because it was so
burdensome, and because virtually everyone works online now anyway.

2) Building the PG docs on Windows is nigh-on impossible. Including
the feature you suggest would make it near impossible to build pgAdmin
on Windows - at best it would probably require building the docs on a
Linux system first, which is not acceptable.

> 3. May be, some ready-made open source solution can be used for
> indexing DocBook SGML and later searching? It's searching engine is to
> be incorporated into PgAdmin.

Aside from the issues above, we already have search capabilities in
Sphinx (though, I haven't spent time playing with them yet).

I wonder if an alternate approach to this problem would be to have a
web service on one of our machines that can create the keyword index
of the PostgreSQL docs, that can be downloaded and cached for use by
pgAdmin, or other apps.

>
> I'd like to work on subject and look for any constructive opinions.
> Thanks!
>
> --
> Best regards,
>  J.F.
>
>
>
> --
> Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgadmin-hackers



--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company