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

Поиск
Список
Период
Сортировка
От Dave Page
Тема Re: [pgadmin-hackers] Ways to improve PgAdmin III SQL context help
Дата
Msg-id CA+OCxoxZ6zXHfP+GG9Xy_bYffsb+k14RaO3QKqY8f++QAK2TwA@mail.gmail.com
обсуждение исходный текст
Ответ на Ways to improve PgAdmin III SQL context help  ("J.F. Oster" <jinfroster@mail.ru>)
Список pgsql-docs
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


В списке pgsql-docs по дате отправления:

Предыдущее
От: Ian Lawrence Barwick
Дата:
Сообщение: Re: PATCH: Warn users about tablespace abuse data loss risk
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: [HACKERS] Viability of text HISTORY/INSTALL/regression README files (was Re: [COMMITTERS] pgsql: Document a few more regression test hazards.)