Tom Lane wrote:
There's also the plan B of scanning pg_class to decide which relfilenode
values are legit. IIRC Bruce did up a patch for this about a year ago,
which I vetoed because I was afraid of the consequences if it removed
data that someone really needed.
I posted a patch like that,
Section 12.1.3. Configurations of the developer docs notes that Fortunately,
PostgreSQL comes with predefined configurations for many languages. (psql's
\dF shows all predefined configurations.) but alas it doesn't seem to.
Welcome to psql 8.3devel, the PostgreSQL interactive terminal.
Robert Treat wrote:
Section 12.1.3. Configurations of the developer docs notes that Fortunately,
PostgreSQL comes with predefined configurations for many languages. (psql's
\dF shows all predefined configurations.) but alas it doesn't seem to.
Welcome to psql 8.3devel, the PostgreSQL
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
Someone just mentioned doing the same
thing but pushing the unreferenced files into a trash directory
instead of actually deleting them.
That sounds like a good idea to me.
It suddenly strikes me that there's lots of precedent for
Robert Treat [EMAIL PROTECTED] writes:
postgres=# \dF
Did not find any relation named F.
Works for me. When did you last recompile psql?
regression=# \dF
List of text search configurations
Schema |Name| Description
Tom Lane wrote:
There's also the plan B of scanning pg_class to decide which relfilenode
values are legit. IIRC Bruce did up a patch for this about a year ago,
which I vetoed because I was afraid of the consequences if it removed
data that someone really needed. Someone just mentioned doing
Gregory Maxwell [EMAIL PROTECTED] writes:
There seems to be some behavior change in current CVS with respect to
gist and gin indexes on varchar[]. Some side effect of the tsearch2
merge?
I think more likely I broke it during the opfamily rewrite :-(. Looks
like I left out entries for _varchar
On 9/2/07, Tom Lane [EMAIL PROTECTED] wrote:
Marko Kreen [EMAIL PROTECTED] writes:
On 9/1/07, Tom Lane [EMAIL PROTECTED] wrote:
One problem is that we'd have to make CURRENT a reserved word to make it
work exactly like that. Can anyone think of a variant syntax that
doesn't need a new
Florian G. Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
We could perhaps get away with defining that as being the behavior,
but it doubtless will surprise someone sometime. What *should* these
interactions be like, and has anyone got an idea how to implement their
suggestion?
What will
Marko Kreen [EMAIL PROTECTED] writes:
On 9/2/07, Tom Lane [EMAIL PROTECTED] wrote:
Seems a little verbose, but maybe we could do SET var FROM CURRENT
or SET var FROM SESSION?
I'd prefer FROM SESSION then. FROM CURRENT seems unclear.
Actually, I think FROM SESSION is unclear, as it opens the
On Sun, 2007-09-02 at 12:11 -0400, Tom Lane wrote:
I think we pretty clearly want to have it take the currently active
setting, and I'd vote for FROM CURRENT as the best way of expressing
that.
FROM CURRENT sounds good to me.
Another idea (just brainstorming): SET var AS CURRENT.
Regards,
On Sat, 2007-09-01 at 15:03 -0400, Tom Lane wrote:
ALTER FUNCTION func(args) SET var TO CURRENT;
Hmmm ... that's certainly do-able, though I'm not sure how much it helps
the use-case you suggest. The search path still has to be set at the
top of the module script, no?
It gives some better
Dear PostgreSQL Hackers:
After following the hackers mailing list for quite a while,
I am going to start investigating what will need to be done
to improve hash index performance. Below are the pieces of
this project that I am currently considering:
1. Characterize the current hash index
On Sat, 2007-09-01 at 13:55 -0400, Tom Lane wrote:
You already have that issue with respect to the default public execute
permissions on the function. The standard solution is to do it in a
transaction block --- then no one can even see the function until you
commit.
It might be a good idea
On Fri, Aug 31, 2007 at 3:10 PM, in message [EMAIL PROTECTED],
Tom Lane [EMAIL PROTECTED] wrote:
Hmm. Do I correctly grasp the picture that you've got several Postgres
installations on the machine and they're all booted by startup scripts?
In this situation, it's actually not a bad idea
Hello
I am found small bug
postgres=# CREATE TEXT SEARCH DICTIONARY cz1(TEMPLATE = ispell,
DictFile= 'cs_czutf');
ERROR: invalid text search configuration file name cs_czutf
postgres=# CREATE TEXT SEARCH DICTIONARY cz1(TEMPLATE = ispell,
DictFile= 'csczutf8');
ERROR: invalid text search
On Thu, 2007-08-30 at 21:00 -0400, Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
... So at least for the pl/pgsql case, it seems easy enough to temporarily
change GUCs already. For other PLs, things might be different though -
I wouldn't know, I have never really used them...
I just tried on CVS HEAD and seems something is broken
postgres=# CREATE TEXT SEARCH DICTIONARY ru_ispell (
TEMPLATE = ispell,
DictFile = russian-utf8.dict,
AffFile = russian-utf8.aff,
StopWords = russian
);
ERROR: syntax error at or near -
LINE 3: DictFile =
Oleg Bartunov [EMAIL PROTECTED] writes:
postgres=# CREATE TEXT SEARCH DICTIONARY ru_ispell (
TEMPLATE = ispell,
DictFile = 'russian-utf8.dict',
AffFile = 'russian-utf8.aff',
StopWords = russian
);
ERROR: invalid text search configuration file name
[EMAIL PROTECTED] wrote:
Hi Tom and Andrew,
On Thu, 30 Aug 2007, Tom Lane wrote:
While waiting for my application for another animal, I made some tests and
was surprised that cluster test failed with an ordering error.
This is running with CLOBBER_CACHE_ALWAYS set, right? I think it is
Tom Lane [EMAIL PROTECTED] writes:
Oleg Bartunov [EMAIL PROTECTED] writes:
postgres=# CREATE TEXT SEARCH DICTIONARY ru_ispell (
TEMPLATE = ispell,
DictFile = 'russian-utf8.dict',
AffFile = 'russian-utf8.aff',
StopWords = russian
);
ERROR: invalid
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
I made it reject all but latin letters, which is the same restriction
that's in place for timezone set filenames. That might be overly
strong, but we definitely have to forbid . and / (and \ on
Windows). Do we want
Alvaro Herrera [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
While waiting for my application for another animal, I made some tests and
was surprised that cluster test failed with an ordering error.
This is running with CLOBBER_CACHE_ALWAYS set, right? I think it is
quite possible that
On Sunday 02 September 2007 10:29, Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
postgres=# \dF
Did not find any relation named F.
Works for me. When did you last recompile psql?
Blah I compiled last night, using the latest snapshot in the
postgresql/dev/ directory in ftp,
Robert Treat [EMAIL PROTECTED] writes:
Blah I compiled last night, using the latest snapshot in the
postgresql/dev/ directory in ftp, which, as I look now, has a date listed of
2007-08-10, and looking in the source the catversion is 200702251, which is
before the tsearch bits hit the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Should be fixed now, running a manual run of it right now, give it about 15
minutes or so ...
- --On Sunday, September 02, 2007 21:48:36 -0400 Robert Treat
[EMAIL PROTECTED] wrote:
On Sunday 02 September 2007 10:29, Tom Lane wrote:
Robert Treat
Kenneth Marshall [EMAIL PROTECTED] writes:
... This is the rough plan. Does anyone see anything critical that
is missing at this point?
Sounds pretty good. Let me brain-dump one item on you: one thing that
hash currently has over btree is the ability to handle index items up
to a full page.
27 matches
Mail list logo
