Chad Wagner [EMAIL PROTECTED] writes:
Just a heads up, not sure if you guys are aware of it. But one of the
Makefile's (src/backend/tsearch/Makefile) added by this patch breaks the
build out of source tree feature of autoconf/automake. The problem is
pretty straightforward, and after adding
On 8/14/07, Gregory Stark [EMAIL PROTECTED] wrote:
Tom Lane [EMAIL PROTECTED] writes:
Doesn't this design completely fail to take index bloat into account?
Repairing heap fragmentation does not reduce the need for VACUUM to work
on the indexes.
Index bloat is a bit of an open issue
Hi list,
Le mardi 21 août 2007, Tom Lane a écrit :
CREATE TEXT SEARCH DICTIONARY swedish (
TEMPLATE = snowball,
LANGUAGE = swedish,
STOPWORDS = swedish
);
ALTER TEXT SEARCH DICTIONARY swedish (
STOPWORDS
);
this dictionary would have LANGUAGE = swedish and no stopwords
Le mardi 21 août 2007, Oleg Bartunov a écrit :
On Mon, 20 Aug 2007, Tom Lane wrote:
I've applied version 0.58 of the patch with a lot of further
editorializing. I feel fairly confident now in the code that interfaces
Great ! Just checked and most things after trivial changes are working !
Tom Lane [EMAIL PROTECTED] writes:
After starting to document this stuff I'm wondering whether it really
makes sense to change the parser associated with a tsearch
configuration. The problem is that the new parser might have an
unrelated set of token types, but we don't do anything about
Tom Lane wrote:
Applied, thanks. (Hm, I thought we had some buildfarm machines testing
VPATH builds these days? Guess not ...)
I have switched dungbeetle to use vpath. It's a one line config file
change, and it builds every hour (3 a day for stable banches, remainder
for HEAD) if
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
I'm not sure if this is a sane way to set up a dictionary, but surely
seg faulting is not the right thing to do. Should we throw an error on
an empty dict file, or should we swallow it without crashing?
Offhand I'd say that
Dimitri Fontaine [EMAIL PROTECTED] writes:
I don't understand why this ALTER variation is so different from existing=20
ones, but maybe the following syntax can't work:
ALTER TEXT SEARCH DICTIONARY swedish ALTER STOPWORDS SET swedish;
You'd have to repeat the whole command for each option to
Hamid Quddus Akhtar [EMAIL PROTECTED] writes:
Offhand I'd say that an empty file is a legitimate corner case,
so we should just take it silently.
Shouldn't we be warning about an empty file rather than just swallowing
up the error?
You are jumping to a conclusion, namely that it is an
Tom Lane wrote:
Hamid Quddus Akhtar [EMAIL PROTECTED] writes:
Offhand I'd say that an empty file is a legitimate corner case,
so we should just take it silently.
Shouldn't we be warning about an empty file rather than just swallowing
up the error?
You are jumping to a conclusion,
Tom Lane wrote:
Dimitri Fontaine [EMAIL PROTECTED] writes:
I don't understand why this ALTER variation is so different from existing=20
ones, but maybe the following syntax can't work:
ALTER TEXT SEARCH DICTIONARY swedish ALTER STOPWORDS SET swedish;
You'd have to repeat the whole command
Teodor Sigaev [EMAIL PROTECTED] writes:
I also made these statements verify that the tmplinit method will accept
the new settings before they get stored; in the original coding you didn't
find out about mistakes until the dictionary got invoked.
That is source of initdb error with -E KOI8-R
I notice that the existing tsearch documentation that we've imported
fairly consistently refers to Snowball dictionaries with names like
en_stem, ru_stem, etc. However, CVS HEAD is set up to create them
with names english, russian, etc. As I've been absorbing more of
the docs I'm starting to
Bruce Momjian wrote:
Tom Lane wrote:
Hamid Quddus Akhtar [EMAIL PROTECTED] writes:
Offhand I'd say that an empty file is a legitimate corner case,
so we should just take it silently.
Shouldn't we be warning about an empty file rather than just swallowing
up the error?
You are jumping to a
On Aug 22, 2007, at 11:10 , Tom Lane wrote:
I notice that the existing tsearch documentation that we've imported
fairly consistently refers to Snowball dictionaries with names like
en_stem, ru_stem, etc. However, CVS HEAD is set up to create them
with names english, russian, etc. As I've
Sounds reasonable, but why exactly did we spell out english instead of en ?
Seems the abbrev is much easier to extract from LANG or browser prefs ...
Andreas
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Tom Lane
Gesendet: Mittwoch, 22.
Hmm. That's a problem, but I don't think that not having any error
checking on CREATE TEXT SEARCH DICTIONARY's parameters is a good
solution.
Agreed
The first kluge that comes to mind is to suppress the error check in a
standalone backend (ie, when not IsUnderPostmaster), which would cover
Teodor Sigaev [EMAIL PROTECTED] writes:
The first kluge that comes to mind is to suppress the error check in a
standalone backend (ie, when not IsUnderPostmaster), which would cover
the initdb case. But maybe there are better answers ... any ideas?
Don't see, but that's connected only to
Merlin Moncure wrote:
On 8/21/07, Magnus Hagander [EMAIL PROTECTED] wrote:
OTOH, if we do it as a compat package, we need to set a firm end-date on
it, so we don't have to maintain it forever.
I would suggest making a pgfoundry project...that's what was done with
userlocks. I'm pretty
Zeugswetter Andreas ADI SD [EMAIL PROTECTED] writes:
Sounds reasonable, but why exactly did we spell out english instead of en
?
Seems the abbrev is much easier to extract from LANG or browser prefs ...
Mainly because we're following the upstream snowball project on the
naming.
I don't think
Is the file format for the ispell dictionary documented somewhere?
There's apparently support for an old and a new format, but I can't
figure out what the formats are.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of
On Wed, 22 Aug 2007, Tom Lane wrote:
I notice that the existing tsearch documentation that we've imported
fairly consistently refers to Snowball dictionaries with names like
en_stem, ru_stem, etc. However, CVS HEAD is set up to create them
with names english, russian, etc. As I've been
On Wed, 22 Aug 2007, Heikki Linnakangas wrote:
Is the file format for the ispell dictionary documented somewhere?
There's apparently support for an old and a new format, but I can't
figure out what the formats are.
ispell, myspell and hunspell formats are supported automagically.
They are
Hackers,
We had a massive power outage in the Norway lab. So please ignore any
failures from the Sun/Solaris buildfarm servers for the next 48 hours.
--Josh
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
[EMAIL PROTECTED] (Peter Eisentraut) writes:
Log Message:
---
Add configure option --with-system-tzdata to use operating system time zone
database.
While this looked like a reasonable idea in the abstract, it turns out
that it was probably a waste of time. Red Hat distributions, at
Tom Lane [EMAIL PROTECTED] writes:
In the first place, it is considered bad form for a package to install
an absolute symlink to /usr/share/zoneinfo:
symlinks _should_ be relative. Even if all they have in common is /.
- Jeremy Katz
Hopefully this is the right place for a few feature requests that
would address some of the things that I've noticed in postgres.
1. Just a minor annoyance, but why must subqueries in FROM clauses
have an alias? For instance suppose that I have an orders table, and
one of the fields is userid.
Tom Lane wrote:
Red Hat distributions, at least, will never be able to use it in the
given form.
This just encoded what a packager would presumably have done anyway. If
it's not going to work for Red Hat, then it's never going to work for
Red Hat in any way without major reeingineering (such
Gregory Stark wrote:
Why would --with-zoneinfo want to use a symlink though? Shouldn't it
just compile the binary to use the path specified directly?
The way this question is posed appears to imply that doing the latter is
easier, but it's not. If someone wants to do the extra work, maybe
Ben,
pgsql-sql is probably the appropriate list for future queries of this
nature.
Note that the below is my personal opinion; each PG developer has their
own.
1. Just a minor annoyance, but why must subqueries in FROM clauses
have an alias? For instance suppose that I have an orders
On Aug 22, 2007, at 18:45 , Ben Tilly wrote:
1. Just a minor annoyance, but why must subqueries in FROM clauses
have an alias?
It's required by the SQL standard, AIUI. I wonder what EnterpriseDB
does?
2. Why is 'non-integer constant in GROUP BY' an error?
This works for now:
case
Ben Tilly [EMAIL PROTECTED] writes:
Hopefully this is the right place for a few feature requests that
would address some of the things that I've noticed in postgres.
1. Just a minor annoyance, but why must subqueries in FROM clauses
have an alias? For instance suppose that I have an orders
Peter Eisentraut [EMAIL PROTECTED] writes:
Gregory Stark wrote:
Why would --with-zoneinfo want to use a symlink though? Shouldn't it
just compile the binary to use the path specified directly?
The way this question is posed appears to imply that doing the latter is
easier, but it's not. If
On 8/22/07, Michael Glaesemann [EMAIL PROTECTED] wrote:
On Aug 22, 2007, at 18:45 , Ben Tilly wrote:
1. Just a minor annoyance, but why must subqueries in FROM clauses
have an alias?
It's required by the SQL standard, AIUI. I wonder what EnterpriseDB
does?
I can well believe that the
On 8/22/07, Gregory Stark [EMAIL PROTECTED] wrote:
Ben Tilly [EMAIL PROTECTED] writes:
Hopefully this is the right place for a few feature requests that
would address some of the things that I've noticed in postgres.
1. Just a minor annoyance, but why must subqueries in FROM clauses
Ben Tilly wrote:
On 8/22/07, Gregory Stark [EMAIL PROTECTED] wrote:
Ben Tilly [EMAIL PROTECTED] writes:
2. Why is 'non-integer constant in GROUP BY' an error?
Hm... I was a bit surprised by this warning myself. IIRC there was an
implementation convenience issue.
If your implementation
On Aug 22, 2007, at 20:36 , Ben Tilly wrote:
On 8/22/07, Michael Glaesemann [EMAIL PROTECTED] wrote:
On Aug 22, 2007, at 18:45 , Ben Tilly wrote:
1. Just a minor annoyance, but why must subqueries in FROM clauses
have an alias?
It's required by the SQL standard, AIUI. I wonder what
On Aug 22, 2007, at 20:49 , Ben Tilly wrote:
If your implementation accepts:
group by case when true then 'foo' end
What would that mean? Regardless of whether or not it's accepted, it
should have *some* meaning.
It's not equivalent to GROUP BY foo
test=# select record_id as foo
[ catching up on today's email ]
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
In the first place, it is considered bad form for a package to install
an absolute symlink to /usr/share/zoneinfo:
Fwiw Debian also faced this issue and came to a different conclusion.
Michael Glaesemann [EMAIL PROTECTED] writes:
On Aug 22, 2007, at 20:36 , Ben Tilly wrote:
I can well believe that the standard says that you must accept
subqueries with aliases. But does it say you must reject subqueries
without aliases? I strongly doubt that.
If I'm reading my draft copy
40 matches
Mail list logo
