Ross and Chris,
I was reading too fast :-)
The problem is actually more complex:
We have to distinguish 4 cases when Query could returns zero result:
1. normal - there are no such words
2. query consists of stop-words only
3. query consists of lexems of non-indexed clasess (specified in parser
It's nonlocal constraints that are the problem, and here foreign keys
and UNIQUE constraints are certainly the canonical examples. Both of
these would be largely solved with table-spanning indexes I think.
Note that the other obvious way to solve this would be to store all of
the
Bruce Momjian wrote:
I am willing to talk to anyone about this. There is a reason my phone
number is in my signature (note new phone number; I just moved.)
Also, I am willing to make trips to companies to talk about
PostgreSQL.
I can't make 100's of trips a year, but I try to do at
I think the areas are at least two -
- funding - who funds it and areas that need funding
- PR - what I described in my previous mail
These are pretty separated.
Iavor
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to
On Thu, 15 Aug 2002, Bruce Momjian wrote:
I have seen some negative reactions to the feature. I am willing to ask
for a vote, if that is what people want. If not, I will apply the patch
in the next day or two.
So are you calling for a vote or just willing to ask for one? I vote for
No you can use:
regression=# select 'the'::mquery_txt;
ERROR: Your query contained only stopword(s), ignored
regression=# select 'good'::mquery_txt;
mquery_txt
'good'
(1 row)
I suggest:
1.
regression=# select 'the'::mquery_txt;
NOTICE: Your query contained only
Hi,
I'm using the ltree module and located several problems, I think not all problems are
really ltree related but might be a pg_dump/pg_restore problem.
Here are the problems I've encountered:
* pg_restore tries to create a table with ltree and ltree[] datatypes before the type
itself is
This is known problem with pg_dump.
Don't remember if it's solved in 7.3
Regards,
Oleg
On Fri, 16 Aug 2002, Mario Weilguni wrote:
Hi,
I'm using the ltree module and located several problems, I think not all problems
are really ltree related but might be a
On Fri, 16 Aug 2002, Christopher Kings-Lynne wrote:
Ross - maybe we could work on a little function for tsearch - parse_query()
or something like that. It could return true or false depending on whether
it would cause tsearch to error or not...
In principle, the right way is to use the same
Neil Conway [EMAIL PROTECTED] writes:
I don't see a major problem with allowing postgres to login if the
connection limit is hit (although I'm not sure it's worth the worry,
when 'kill a backend executing SELECT ; psql template1 postgres' works
as-is).
max_connections is a hard limit; you do
Vince Vielhaber [EMAIL PROTECTED] writes:
So are you calling for a vote or just willing to ask for one? I vote for
putting it in contrib and letting whoever wants it apply it and use it.
The trouble with putting it in contrib is that that makes it effectively
unavailable to anyone who
Mario Weilguni [EMAIL PROTECTED] writes:
Here are the problems I've encountered:
* pg_restore tries to create a table with ltree and ltree[] datatypes before the
type itself is created, so it fails.
Odd; what are the OIDs of the table and the datatypes?
* several functions are already
Matthew T. O'Connor wrote:
Hello, I'm playing with creating an auto vacuum daemon, but it is my first
time inside the pg source code and I'm a bit lost.
I have gotten as far as having a vacuum daemon created on postmaster startup.
It's just a fork from the postmaster, cribbed mostly from
Bruce Momjian [EMAIL PROTECTED] writes:
Reindex/btree shrinkage - does reindex need work, can btree be shrunk?
I think there is zero probability that anything will be finished on this
in the next two weeks, considering that (a) no one is working on it,
and (b) it's not a small task. Push it
On Thu, 2002-08-15 at 15:36, Tom Lane wrote:
Well, I am, but I'm only speaking for myself here:
Fair enough.
I think there is room for several replication solutions for Postgres
(three or four, maybe).
If the ideal solution count is merely one with a maybe on two then I
tend to concur
On Fri, 16 Aug 2002, Tom Lane wrote:
Vince Vielhaber [EMAIL PROTECTED] writes:
So are you calling for a vote or just willing to ask for one? I vote for
putting it in contrib and letting whoever wants it apply it and use it.
The trouble with putting it in contrib is that that makes it
Greg Copeland [EMAIL PROTECTED] writes:
I guess I should ask. Do the developers foresee immediate usability
from [Postgres-R] or are we looking at something that's a year+ away?
Darren Johnson would be the man to answer that, but from what he said
at OSCON it sounded like we'd be seeing
Vince Vielhaber writes:
[ 'user@' patch ]
whim. Then again as long as 7.2.1 is stable enough for me there's
no reason to upgrade 'cuze I damn sure ain't going back and changing
all sorts of programs and scripts that have global users.
Having read bits and pieces of this thread, can
Lee Kindness [EMAIL PROTECTED] writes:
Vince Vielhaber writes:
[ 'user@' patch ]
whim. Then again as long as 7.2.1 is stable enough for me there's
no reason to upgrade 'cuze I damn sure ain't going back and changing
all sorts of programs and scripts that have global users.
Having read
On Fri, Aug 16, 2002 at 10:21:12AM -0400, Vince Vielhaber wrote:
RPMs aren't a good enough reason to put it in. All features aren't
installed in an RPM, why would this need to? Besides, anything that
is runtime configurable can end up getting its default changed on a
whim. Then again as
On Fri, 2002-08-16 at 09:51, Ross J. Reedstrom wrote:
On Fri, Aug 16, 2002 at 10:21:12AM -0400, Vince Vielhaber wrote:
RPMs aren't a good enough reason to put it in. All features aren't
installed in an RPM, why would this need to? Besides, anything that
is runtime configurable can
Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
I don't see a major problem with allowing postgres to login if the
connection limit is hit (although I'm not sure it's worth the worry,
when 'kill a backend executing SELECT ; psql template1 postgres' works
as-is).
max_connections
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Reindex/btree shrinkage - does reindex need work, can btree be shrunk?
I think there is zero probability that anything will be finished on this
in the next two weeks, considering that (a) no one is working on it,
and (b) it's not a
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
I'm running Red Hat 7.3 at home. For the fun of it, I put:
#define NO_MKTIME_BEFORE_1970
But I'm still getting the 1970 regression test failures. What else do
I need to do?
I'd assume you need to select different regression
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
What does -f do?
There is concern that using pg_resetxlog by accident could cause
problems, so it will prompt the user for confirmation by default. -f
(force) disables that confirmation.
pg_resetxlog already has an -f switch,
Absolutely, I have been looking into this and I have some thoughts, but right
now all I was trying to do was some rough implementations just to help me
make sure I understand all / most of the issues. I am very new to hacking on
the guts of the backend.
I plan on posting a formal proposal
Vince Vielhaber wrote:
On Thu, 15 Aug 2002, Bruce Momjian wrote:
I have seen some negative reactions to the feature. I am willing to ask
for a vote, if that is what people want. If not, I will apply the patch
in the next day or two.
So are you calling for a vote or just willing to
Curt Sampson wrote:
On Thu, 15 Aug 2002, Bruce Momjian wrote:
I would like to know how to move this item forward.
Right now (i.e., in 7.2), the only two options we have for moving the
log file to a different spindle are mounting it on pg_xlog and using a
symlink. I doubt many people do
On Fri, 16 Aug 2002 01:05:07 -0400 (EDT), Bruce Momjian
[EMAIL PROTECTED] wrote:
P O S T G R E S Q L
7 . 3 O P E NI T E M S
improve macros in new tuple header code (Manfred)
ISTM there's no consensus about what improve means. I
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
We could consider establishing a soft connection limit that's somewhat
less than max_connections, and allowing non-superusers to log in only
if the soft limit hasn't been exceeded. This does not guarantee that
superusers can always get
Manfred Koizar wrote:
On Fri, 16 Aug 2002 01:05:07 -0400 (EDT), Bruce Momjian
[EMAIL PROTECTED] wrote:
P O S T G R E S Q L
7 . 3 O P E NI T E M S
improve macros in new tuple header code (Manfred)
ISTM there's no consensus
Bruce Momjian [EMAIL PROTECTED] writes:
I hadn't looked at flags yet. Thomas's concern, and I think a valid
one, is that if we move it from contrib into the main tree, people may
accidentally run pg_resetxlog without understanding the issues involved.
There's already an interlock to prevent
Bruce Momjian [EMAIL PROTECTED] writes:
Specifically, what is ugly about it? Is it that global users have an @
at the end of their names? How do we prevent namespace collisions
_without_ doing this? I am all ears.
The folks who are unhappy about this design basically think that the
Then shouldn't this appear on the Open 7.3 issues list that has been
circulating around? This seems like an open issue to me, that needs to
be addressed before 7.3 ships.
--Barry
Tom Lane wrote:
Barry Lind [EMAIL PROTECTED] writes:
You can no long insert large values into a bigint
Joe Conway [EMAIL PROTECTED] writes:
Is /src/include/port/linux.h the correct place to put this or should
something more specific to Red Hat 7.3 be used (and if so, any ideas
about how to detect that Red Hat 7.3 is being used)?
Really what we need is a test on the glibc version, which seems
Barry Lind [EMAIL PROTECTED] writes:
Then shouldn't this appear on the Open 7.3 issues list that has been
circulating around?
It does.
regards, tom lane
---(end of broadcast)---
TIP 3: if posting/reading through Usenet,
OK, sounds reasonable.
---
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I hadn't looked at flags yet. Thomas's concern, and I think a valid
one, is that if we move it from contrib into the main tree,
On Fri, 16 Aug 2002, Tom Lane wrote:
Lee Kindness [EMAIL PROTECTED] writes:
Vince Vielhaber writes:
[ 'user@' patch ]
whim. Then again as long as 7.2.1 is stable enough for me there's
no reason to upgrade 'cuze I damn sure ain't going back and changing
all sorts of programs and
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
We could consider establishing a soft connection limit that's somewhat
less than max_connections, and allowing non-superusers to log in only
if the soft limit hasn't been exceeded. This does not guarantee that
It is already there, I think:
fix implicit type coercions that are worse
---
Barry Lind wrote:
Then shouldn't this appear on the Open 7.3 issues list that has been
circulating around? This seems like an open
Vince Vielhaber wrote:
Once again: *no one* has at any time suggested that any form of this
patch should affect the default behavior in the slightest.
Not yet they haven't. What happens when it's decided that this
*feature* is a good thing and should be the default? Maybe not
now, but
On Fri, 16 Aug 2002, Ross J. Reedstrom wrote:
On Fri, Aug 16, 2002 at 10:21:12AM -0400, Vince Vielhaber wrote:
RPMs aren't a good enough reason to put it in. All features aren't
installed in an RPM, why would this need to? Besides, anything that
is runtime configurable can end up
Vince Vielhaber [EMAIL PROTECTED] writes:
My point has nothing to do with resistance to GUC configurables. Someone
WILL decide that having it as a default is a *Good Thing* because it's
there and is useful to them
Which someone would this be? There's no chance that such a proposal
would
BTW, I just thought of a small improvement to your patch that eliminates
some of the ugliness. Suppose that when we recognize an attempt to
connect as a global user (ie, feature flag is on and last character of
username is '@'), we strip off the '@' before proceeding. Then we would
have:
Bruce Momjian wrote:
Jan Wieck wrote:
Bruce Momjian wrote:
Allow PL/PgSQL functions to return sets
Is anyone working on this? We will get beaten up if we don't have this
for 7.3 and it is available in other languages.
That's true. I think I have to do this one.
Jan Wieck [EMAIL PROTECTED] writes:
Since PL/pgSQL is a loadable module still, we might be able to provide
an upgrade after 7.3 is out instead of waiting for 7.4.
Maybe, but you'd have to get the core-code end of it in before beta.
AFAIR Joe's patch doesn't yet cover any return style from a
Tom Lane wrote:
BTW, I just thought of a small improvement to your patch that eliminates
some of the ugliness. Suppose that when we recognize an attempt to
connect as a global user (ie, feature flag is on and last character of
username is '@'), we strip off the '@' before proceeding. Then
On Fri, 2002-08-16 at 20:03, Bruce Momjian wrote:
Sure. If I can get one more 'yes' I will submit a new patch with the
change. It does prevent the namespace collision without mucking up
pg_shadow. We only need to tell people that global users need to supply
their username to the client as
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
Since PL/pgSQL is a loadable module still, we might be able to provide
an upgrade after 7.3 is out instead of waiting for 7.4.
Maybe, but you'd have to get the core-code end of it in before beta.
AFAIR Joe's patch doesn't yet cover any
Joe Conway wrote:
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
Since PL/pgSQL is a loadable module still, we might be able to provide
an upgrade after 7.3 is out instead of waiting for 7.4.
Maybe, but you'd have to get the core-code end of it in before beta.
AFAIR Joe's
Is it possible for the cvs emails to include a URL to the appropriate
entries in cvs web?
The below is current:
Modified files:
src/backend/utils/adt: ruleutils.c
Is this possible?
Modified files:
Rod Taylor wrote:
Modified files:
src/backend/utils/adt: ruleutils.c
Is this possible?
Modified files:
http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/utils/adt/ruleutils.c
I'd second that request! Great idea.
Joe
---(end of
A recent change made XLogDir dynamically sized. There was a question of
whether this was a good idea since there are lots of other places that
use MAXPGPATH.
I have now found that pg_resetxlog doesn't compile anymore because
XLogDir is a char* now instead of a char[].
Should I fix pg_resetxlog
On Fri, 16 Aug 2002 12:25:37 -0400 (EDT), Bruce Momjian
[EMAIL PROTECTED] wrote:
Manfred Koizar wrote:
This is the main point of disagreement: Tom Lane wants lighter
macros, I want heavier macros. Which direction shall we go?
Could you or Tom explain that in a way that others could
It is certainly possibly. We have added that type of functionality to
our inhouse CVS system. Below is an example. We include at the bottom
of the checkin mail a link to the webcvs diff page so you can quickly
see what changed for a particular checkin.
--Barry
wfs checkin by barry
[EMAIL PROTECTED] (Bruce Momjian) wrote
I know the trailing @ is ugly, but it prevents surpises when connecting
to the database.
if you would make the magic character a variable then perhaps you could
prevent the ugly... if/when you turn off the feature, you could set the
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Bruce Momjian) wrote
I know the trailing @ is ugly, but it prevents surpises when connecting
to the database.
if you would make the magic character a variable then perhaps you could
prevent the ugly... if/when you turn off the feature,
From earlier postings it seems like there is no way to check that a temp
table exists; at the time Tom suggested schemas might solve the problem. I
was wondering if:
(a) schema did solve the problem
or
(b) there was any chance of a backend function to get a temp table OID
(or 0
This has been discussed before in the context of misunderstanding the
meaning of 'iscachable', but I now have a use for cached function results,
and have seen at least one other posting with a similar need.
The reason I need it is that I have a few functions that do recursive
inheritance
Bruce Momjian [EMAIL PROTECTED] writes:
A recent change made XLogDir dynamically sized. There was a question of
whether this was a good idea since there are lots of other places that
use MAXPGPATH.
I have now found that pg_resetxlog doesn't compile anymore because
XLogDir is a char* now
OK, here is the patch with the suggested changes. I am sending the
patch to hackers because there has been so much interest in this.
---
Tom Lane wrote:
BTW, I just thought of a small improvement to your patch that
Philip Warner [EMAIL PROTECTED] writes:
Obviously this is not a 7.3 item, but would people support such
functionality going into a future version?
Actually, I wouldn't. I can think of very few situations where
such caching is useful, and I don't believe that the mechanism required
would pay
Sample run:
$ psql -U postgres test
psql: FATAL: user postgres@test does not exist
$ psql -U postgres@ test
Welcome to psql 7.3devel, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
A recent change made XLogDir dynamically sized. There was a question of
whether this was a good idea since there are lots of other places that
use MAXPGPATH.
I have now found that pg_resetxlog doesn't compile anymore because
64 matches
Mail list logo
