"Tom Lane" <[EMAIL PROTECTED]> writes:
> 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
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.
-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 T
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 t
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/ directo
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 possi
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
>> Win
"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
>> );
>>
[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
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 na
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 =
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
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 confi
>>> 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
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 id
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 implemen
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 b
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,
"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,
"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?
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
> >> do
"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 _v
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 the
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
+-
"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
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 Postgre
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.
Typ
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 th
28 matches
Mail list logo
