Re: [PATCHES] tsearch limitations doc correction
On Tue, 2007-10-09 at 19:31 +0100, Heikki Linnakangas wrote: [...] Applied, thanks. -Neil ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Preliminary patch for tsearch example dictionaries/parsers in contrib
Tom Lane <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] (Sergey V. Karpov) writes: >> Tom Lane <[EMAIL PROTECTED]> writes: >>> I think the consensus is for one module per top-level contrib directory. > >> Please excuse me, but English is not my native language, and I don't >> understand your phrase. Do you mean one module with two dictionaries and >> a parser at once, or three different modules in contrib/? > > Sorry --- I meant they should be set up as three independent contrib > modules. Ok. I've made it. The code is again at http://lynx.sao.ru/~karpov/tmp/ts_examples.tar.gz Sincerely your, Sergey Karpov ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] Preliminary patch for tsearch example dictionaries/parsers in contrib
[EMAIL PROTECTED] (Sergey V. Karpov) writes: > Tom Lane <[EMAIL PROTECTED]> writes: >> I think the consensus is for one module per top-level contrib directory. > Please excuse me, but English is not my native language, and I don't > understand your phrase. Do you mean one module with two dictionaries and > a parser at once, or three different modules in contrib/? Sorry --- I meant they should be set up as three independent contrib modules. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Preliminary GSSAPI Patches
I'm not suggesting any change. Merely correcting a misstatement I made earlier. I believe the documentation already recommends best practice. On Oct 10, 2007, at 10:53 AM, Magnus Hagander wrote: Tom Lane wrote: "Henry B. Hotz" <[EMAIL PROTECTED]> writes: You know, I don't know what I was thinking when I sent this. My apologies for the late correction. Anyone who has a copy of the "host" keys for a machine can manufacture kerberos tickets for the "host" service on that machine masquerading as absolutely anyone (including people who don't exist). Same for the "postgres" keys, and if the postgres server can steal the host keys (or vice versa) then it's even worse. [snip...] Maybe I'm too dense, but I don't see a conclusion here. Do we need to change our code, our docs, both, or neither? I don't think we do. If you use service keys per our documentation, you should be fine. And if someone owns your host keys, you lost already. //Magnus The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] Preliminary patch for tsearch example dictionaries/parsers in contrib
Tom Lane <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] (Sergey V. Karpov) writes: >> I've prepared reduced and renamed version of the examples. It may be >> downloaded at >> http://lynx.sao.ru/~karpov/tmp/ts_examples.tar.gz > >> - dict_xsyn now uses the same code to locate its config as built-in >>dictionaries, and can't access files outside >>$(prefix)/share/tsearch_data/. > > Good, did you also fix it to do encoding conversion while reading the file? It has not been so in previous code. I've replaced the download file with fixed version. > >> It still has a complicated source tree with subfolders for each >> example. Have I to break it into three separate contrib modules? Or >> combine into one with three build targets (this will break MSVC build)? > > I think the consensus is for one module per top-level contrib directory. Please excuse me, but English is not my native language, and I don't understand your phrase. Do you mean one module with two dictionaries and a parser at once, or three different modules in contrib/? Sincerely your, Sergey Karpov ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] Preliminary patch for tsearch example dictionaries/parsers in contrib
[EMAIL PROTECTED] (Sergey V. Karpov) writes: > I've prepared reduced and renamed version of the examples. It may be > downloaded at > http://lynx.sao.ru/~karpov/tmp/ts_examples.tar.gz > - dict_xsyn now uses the same code to locate its config as built-in >dictionaries, and can't access files outside >$(prefix)/share/tsearch_data/. Good, did you also fix it to do encoding conversion while reading the file? > It still has a complicated source tree with subfolders for each > example. Have I to break it into three separate contrib modules? Or > combine into one with three build targets (this will break MSVC build)? I think the consensus is for one module per top-level contrib directory. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] Preliminary patch for tsearch example dictionaries/parsers in contrib
Tom Lane <[EMAIL PROTECTED]> writes: > Oleg Bartunov <[EMAIL PROTECTED]> writes: >> On Tue, 9 Oct 2007, Andrew Dunstan wrote: >>> Are we in beta or not? To me, beta means nothing but bug fixes go in, >>> period. No ifs, no buts, no maybes, no exceptions. And that should >>> definitely go for contrib as well. We need a bit of self-discipline around >>> here. > >> the original intention was to have text search companion with code examples >> for dictionaries and parser API and ability to keep them in workable >> condition, instead of having them in SGML documentation. > > Yes. I think that we can justify new contrib code here as a documentation > bug fix: right now, the examples in sections 12.9 and 12.10 are wrong > (obsolete), impossible to maintain (which is why they're obsolete; > they failed to track code changes), and not in a format that's directly > useful as a template for new code. > > However, the dict_regex code is not ready for a number of reasons, > quite aside from the question of whether we want to add a dependency. > I concur with the idea of dropping it for now. > > I'm a bit inclined to drop dict_roman as well, as it seems of > questionable real use, and code-example-wise it adds nothing over > dict_intdict. That would leave us with two dictionary examples and one > parser example, and I think both of the dictionaries look useful enough > to be worth keeping. (In particular I'd not vote for having only > dict_intdict since it does not illustrate how to use a config file > ... and we surely don't want to encourage people to not do that > correctly.) I've prepared reduced and renamed version of the examples. It may be downloaded at http://lynx.sao.ru/~karpov/tmp/ts_examples.tar.gz Changes: - renamed to ts_examples to better reflect its purpose - dict_regex and dict_roman excluded, README corrected correspondingly - dict_xsyn now uses the same code to locate its config as built-in dictionaries, and can't access files outside $(prefix)/share/tsearch_data/. Example config file (which is also used in regression test) is installed to this folder. README.dict_xsyn mentions it. - source reformatted to better match PostgreSQL coding style It still has a complicated source tree with subfolders for each example. Have I to break it into three separate contrib modules? Or combine into one with three build targets (this will break MSVC build)? Sincerely your, Sergey Karpov ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Preliminary GSSAPI Patches
Tom Lane wrote: > "Henry B. Hotz" <[EMAIL PROTECTED]> writes: >> You know, I don't know what I was thinking when I sent this. My >> apologies for the late correction. >> >> Anyone who has a copy of the "host" keys for a machine can >> manufacture kerberos tickets for the "host" service on that machine >> masquerading as absolutely anyone (including people who don't >> exist). Same for the "postgres" keys, and if the postgres server can >> steal the host keys (or vice versa) then it's even worse. >> [snip...] > > Maybe I'm too dense, but I don't see a conclusion here. Do we need to > change our code, our docs, both, or neither? I don't think we do. If you use service keys per our documentation, you should be fine. And if someone owns your host keys, you lost already. //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Preliminary GSSAPI Patches
"Henry B. Hotz" <[EMAIL PROTECTED]> writes: > You know, I don't know what I was thinking when I sent this. My > apologies for the late correction. > > Anyone who has a copy of the "host" keys for a machine can > manufacture kerberos tickets for the "host" service on that machine > masquerading as absolutely anyone (including people who don't > exist). Same for the "postgres" keys, and if the postgres server can > steal the host keys (or vice versa) then it's even worse. > [snip...] Maybe I'm too dense, but I don't see a conclusion here. Do we need to change our code, our docs, both, or neither? regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Preliminary patch for tsearch example dictionaries/parsers in contrib
Oleg Bartunov <[EMAIL PROTECTED]> writes: > On Tue, 9 Oct 2007, Andrew Dunstan wrote: >> Are we in beta or not? To me, beta means nothing but bug fixes go in, >> period. No ifs, no buts, no maybes, no exceptions. And that should >> definitely go for contrib as well. We need a bit of self-discipline around >> here. > the original intention was to have text search companion with code examples > for dictionaries and parser API and ability to keep them in workable > condition, instead of having them in SGML documentation. Yes. I think that we can justify new contrib code here as a documentation bug fix: right now, the examples in sections 12.9 and 12.10 are wrong (obsolete), impossible to maintain (which is why they're obsolete; they failed to track code changes), and not in a format that's directly useful as a template for new code. However, the dict_regex code is not ready for a number of reasons, quite aside from the question of whether we want to add a dependency. I concur with the idea of dropping it for now. I'm a bit inclined to drop dict_roman as well, as it seems of questionable real use, and code-example-wise it adds nothing over dict_intdict. That would leave us with two dictionary examples and one parser example, and I think both of the dictionaries look useful enough to be worth keeping. (In particular I'd not vote for having only dict_intdict since it does not illustrate how to use a config file ... and we surely don't want to encourage people to not do that correctly.) regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] Additional windows codepages
On Wed, Oct 10, 2007 at 12:42:36PM +0100, Dave Page wrote: > The attached patch adds some missing Windows codepage numbers to the > table in chklocale.c. Applied, thanks. //Magnus ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[PATCHES] Additional windows codepages
The attached patch adds some missing Windows codepage numbers to the
table in chklocale.c.
Regards, Dave.
*** src/port/chklocale.c.orig Wed Oct 3 18:16:39 2007
--- src/port/chklocale.c Wed Oct 10 12:30:05 2007
***
*** 72,97
--- 72,103
{PG_UTF8, "UTF-8"},
{PG_UTF8, "utf8"},
+ {PG_UTF8, "CP65001"},
{PG_LATIN1, "ISO-8859-1"},
{PG_LATIN1, "ISO8859-1"},
{PG_LATIN1, "iso88591"},
+ {PG_LATIN1, "CP28591"},
{PG_LATIN2, "ISO-8859-2"},
{PG_LATIN2, "ISO8859-2"},
{PG_LATIN2, "iso88592"},
+ {PG_LATIN2, "CP28592"},
{PG_LATIN3, "ISO-8859-3"},
{PG_LATIN3, "ISO8859-3"},
{PG_LATIN3, "iso88593"},
+ {PG_LATIN3, "CP28593"},
{PG_LATIN4, "ISO-8859-4"},
{PG_LATIN4, "ISO8859-4"},
{PG_LATIN4, "iso88594"},
+ {PG_LATIN4, "CP28594"},
{PG_LATIN5, "ISO-8859-9"},
{PG_LATIN5, "ISO8859-9"},
{PG_LATIN5, "iso88599"},
+ {PG_LATIN5, "CP28599"},
{PG_LATIN6, "ISO-8859-10"},
{PG_LATIN6, "ISO8859-10"},
***
*** 108,113
--- 114,120
{PG_LATIN9, "ISO-8859-15"},
{PG_LATIN9, "ISO8859-15"},
{PG_LATIN9, "iso885915"},
+ {PG_LATIN9, "CP28605"},
{PG_LATIN10, "ISO-8859-16"},
{PG_LATIN10, "ISO8859-16"},
***
*** 132,149
--- 139,160
{PG_ISO_8859_5, "ISO-8859-5"},
{PG_ISO_8859_5, "ISO8859-5"},
{PG_ISO_8859_5, "iso88595"},
+ {PG_ISO_8859_5, "CP28595"},
{PG_ISO_8859_6, "ISO-8859-6"},
{PG_ISO_8859_6, "ISO8859-6"},
{PG_ISO_8859_6, "iso88596"},
+ {PG_ISO_8859_6, "CP28596"},
{PG_ISO_8859_7, "ISO-8859-7"},
{PG_ISO_8859_7, "ISO8859-7"},
{PG_ISO_8859_7, "iso88597"},
+ {PG_ISO_8859_7, "CP28597"},
{PG_ISO_8859_8, "ISO-8859-8"},
{PG_ISO_8859_8, "ISO8859-8"},
{PG_ISO_8859_8, "iso88598"},
+ {PG_ISO_8859_8, "CP28598"},
{PG_SJIS, "SJIS"},
{PG_SJIS, "PCK"},
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
