Apologies! As Alvaro guessed it correctly I was working with 8.2 sources.
Sorry for the noise.
Regards,
Nikhils
On 8/29/07, Tom Lane [EMAIL PROTECTED] wrote:
NikhilS [EMAIL PROTECTED] writes:
The attached patch should fix this.
And break other things, no doubt. needed = 0 is a perfectly
Bruce Momjian [EMAIL PROTECTED] writes:
There is no question things would be clearer with only one text search
data type. The only value I can see to having a tsquery data type is
that you can store a tsquery value in a column, but why would that be
much better than just storing it in a TEXT
On Wed, Aug 29, 2007 at 09:49:03PM -0600, Charlie Savage wrote:
Hmm. Its postgresql 8.2.4 + tsearch2 + tree + postgis. postgis in
turn loads proj4 and geos. I grepped through those 3 libraries source
code and did not find any calls to setlocale. So I don't think so.
So now I'm
On Wed, Aug 29, 2007 at 08:53:55PM -0600, Charlie Savage wrote:
In addition to the encoding issues I have with the 8.2.4 MSVC++ build
(see previous email), there are some other issues that I've run into:
1. The custom build step that generates DEF files for DLLS using a perl
script does
On Wed, Aug 29, 2007 at 08:57:55AM -0400, Andrew Dunstan wrote:
Yoshiyuki Asaba wrote:
I have compiled PostgreSQL 8.2.4 with MinGW on Windows 2000. Then I
have executed initdb as Administrator. However initdb failed with the
following message.
The program postgres is needed by
hi tom ...
the idea behind this is to disable the stats on a certain column
entirely.
this would give me more control about the plan. in this special case
data is changing so frequently that the default values are ways
better than trying to keep the real stats up to date.
in case of
Andrew Dunstan a écrit :
Albert Cervera i Areny wrote:
I'm very strongly in favor of having this documentation. However, I
think
it might make sense to put Contrib Modules as a section under either
Reference or Appendices. Also, I don't think it's necessary to make
each command option
Am Mittwoch, 29. August 2007 20:18 schrieb Neil Conway:
I wonder if it would be possible to keep the master version of the
contrib docs as SGML, and generate plaintext READMEs from it during the
documentation build.
Using asciidoc you could do it the other way around.
--
Peter Eisentraut
Am Mittwoch, 29. August 2007 20:27 schrieb Andrew Dunstan:
Also, let's recall what has previously been discussed for contrib,
namely that we break it out into standard modules
But that would also mean that the documentation system is somewhat
modularized. That is, if I deinstall some module,
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
And I'm quite tempted to not flush the XLOG at all during ABORT, and to
only force synchronous commits if one of the to-be-deleted files is
non-temporary.
+1 on the first, but -1 on the second, because we'd have to track
whether
Hi,
I have recently signed up to run smoke testing of PostgreSQL.
As I understand each animal has a set of configuration that is represented as
icons on the status page.
I wonder how would be it possible to run several configurations on the
same machine? I mean with or without debug, with or
Hi all,
On Tue, 28 Aug 2007, Andrew Dunstan wrote:
Date: Tue, 28 Aug 2007 12:34:46 -0400
From: Andrew Dunstan [EMAIL PROTECTED]
Newsgroups: pgsql.hackers
Subject: Re: [COMMITTERS] pgsql: Fix brain fade in DefineIndex(): it was
continuing to access the
Tom Lane wrote:
Andrew Dunstan
Gabor Szabo wrote:
Hi,
I have recently signed up to run smoke testing of PostgreSQL.
As I understand each animal has a set of configuration that is represented as
icons on the status page.
I wonder how would be it possible to run several configurations on the
same machine? I mean with or
Gabor Szabo wrote:
Hi,
I have recently signed up to run smoke testing of PostgreSQL.
As I understand each animal has a set of configuration that is represented as
icons on the status page.
I wonder how would be it possible to run several configurations on the
same machine? I mean with or
Peter Eisentraut wrote:
Am Mittwoch, 29. August 2007 20:27 schrieb Andrew Dunstan:
Also, let's recall what has previously been discussed for contrib,
namely that we break it out into standard modules
But that would also mean that the documentation system is somewhat
modularized.
[EMAIL PROTECTED] wrote:
Does someone have a box with lots of grunt that can spare some cycles
for a few hours once a week or so?
I've just configure centaur (CentOS 5) like this.
Do you need it for every version (8.1, 8.2) or just HEAD
Do you need it just once a week or every run?
I
Andrew Dunstan [EMAIL PROTECTED] writes:
If you want to design a pluggable documentation system then go for it,
but it's not required by what I understand is the consensus plan for
contrib.
I thought a large part of the desire was to improve the visibility of
the contrib docs, ie, put the
Am Donnerstag, 30. August 2007 15:13 schrieb Andrew Dunstan:
What? No it doesn't. You have missed the key word in the sentence above:
standard. The idea is that the docs will describe the *standard*
modules, i.e. those that ship with the PostgreSQL core distribution
(because they are currently
Florian G. Pflug [EMAIL PROTECTED] writes:
It seems doable, but it's not pretty. One possible scheme would be to
emit a record *after* chosing a name but *before* creating the file,
No, because the way you know the name is good is a successful
open(O_CREAT).
The idea was to log *twice*.
Am Donnerstag, 30. August 2007 15:26 schrieb Tom Lane:
I thought a large part of the desire was to improve the visibility of
the contrib docs, ie, put the docs under the noses of people who have
*not* installed or even heard of the modules. So it's not in the docs
unless you installed it
Andrew Dunstan [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
I've just configure centaur (CentOS 5) like this.
Do you need it for every version (8.1, 8.2) or just HEAD
Do you need it just once a week or every run?
I can also configure wharthog (unixware) like this if you need...
I have
Peter Eisentraut wrote:
Am Donnerstag, 30. August 2007 15:26 schrieb Tom Lane:
I thought a large part of the desire was to improve the visibility of
the contrib docs, ie, put the docs under the noses of people who have
*not* installed or even heard of the modules. So it's not in the docs
On 8/30/07, Andrew Dunstan [EMAIL PROTECTED] wrote:
This isn't really the place to ask about running buildfarm - it has its
own mailing list to which you should have been subscribed.
I am sorry.
Do you mean this?
http://lists.pgfoundry.org/mailman/listinfo/pgbuildfarm-members
I could not find
Gregory Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
There is no question things would be clearer with only one text search
data type. The only value I can see to having a tsquery data type is
that you can store a tsquery value in a column, but why would that be
much better
Florian G. Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
+1 on the first, but -1 on the second, because we'd have to track
whether deleted files are temp or not ... it's very unclear that it'd
be worth the trouble.
I'm confused. smgrcreate already tracks if it created a file for a temp
Bruce Momjian [EMAIL PROTECTED] writes:
Gregory Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
There is no question things would be clearer with only one text search
data type. The only value I can see to having a tsquery data type is
that you can store a tsquery value in a
[EMAIL PROTECTED] writes:
Ok, do you need it on unixware?
do you need it more than once a week?
No, and no.
FYI, centaurc is running make check for 3 hours now and has'nt finished!
You're finding out why I suggested a really low duty cycle ;-)
regards, tom lane
Hi all,
I cant find in the docs about tsearch2 (nor the OlegTeodor's wiki) when
to use @@@ instead of @@.
@@ works in GIST, even with 'lexeme:a' (:a, :bc, etc.. every combination
of a,b,c d part)
@@ doesnt with GIN in the same queries it, PostgreSQL says:
ERREUR: With class of lexeme
Hi Tom
On Thu, 30 Aug 2007, Tom Lane wrote:
Date: Thu, 30 Aug 2007 10:04:34 -0400
From: Tom Lane [EMAIL PROTECTED]
To: Andrew Dunstan [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], PostgreSQL-development pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Re: [COMMITTERS] pgsql: Fix brain fade in
Gregory Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Gregory Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
There is no question things would be clearer with only one text search
data type. The only value I can see to having a tsquery data type is
that you can
Gregory Stark [EMAIL PROTECTED] writes:
How would that happen if there wasn't a tsquery type?
I don't think Bruce is suggesting that the search operand can really
be plain text (or if he is, he's nuts). The question here is whether
there's really a need for a distinction between tsvector and
Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
How would that happen if there wasn't a tsquery type?
I don't think Bruce is suggesting that the search operand can really
be plain text (or if he is, he's nuts). The question here is whether
Yes, that is what I was suggesting
[EMAIL PROTECTED] wrote:
Ok, do you need it on unixware?
do you need it more than once a week?
FYI, centaurc is running make check for 3 hours now and has'nt finished!
The platform probably doesn't matter so much, I suspect. Once a week on
a separately registered animal should be fine.
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
Yeah, an extra fetch of the pg_class row doesn't seem all that nice.
I think you'd want to check it in approximately the same two places
where pg_class_ownercheck() is applied (one for the 1-xact and one for
the
Hi Magnus,
Yeah, this is a known problem, and it's fixed for 8.3. Really, the msvc
build process in 8.2 has a *lot* of rough edges ;-) The code itself builds
fine, but the buildsystem needed a lot more work.
Great - figured that might be the case.
3. If you have a contrib module that is
On Thu, 30 Aug 2007, Bruce Momjian wrote:
Gregory Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
There is no question things would be clearer with only one text search
data type. The only value I can see to having a tsquery data type is
that you can store a tsquery value in a column,
On Thu, 30 Aug 2007, Jean-Paul Argudo wrote:
Hi all,
I cant find in the docs about tsearch2 (nor the OlegTeodor's wiki) when
to use @@@ instead of @@.
it's written here
http://www.sai.msu.su/~megera/postgres/fts/doc/indexes-fts.html
@@ works in GIST, even with 'lexeme:a' (:a, :bc, etc..
I noticed that enums are not available to be queried as binary through
the protocol. Is this a known issue? Too late to fix for 8.3? This
is kind of a pain, because it forces any query that returns an enum to
return the entire result as text. afaik, enums are the only POD type
to behave this
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Why does text search need a tsquery data type? I realize it needs
tsvector so it can create indexes and updated trigger columns, but it
seems tsquery could instead just be a simple text string.
By that logic, we don't need any data
Gregory Stark wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
It seems doable, but it's not pretty. One possible scheme would be to
emit a record *after* chosing a name but *before* creating the file,
No, because the way you know the name is good is a successful
open(O_CREAT).
The idea was
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
+1 on the first, but -1 on the second, because we'd have to track
whether deleted files are temp or not ... it's very unclear that it'd
be worth the trouble.
I'm confused. smgrcreate already tracks if it created a
Ron Mayer [EMAIL PROTECTED] writes:
Could similar logic argue that we'd want special types for regular
expressions too? That seems quite parallel to the tsquery type to me.
Yeah, it certainly seems like something we might want to consider in
future --- we could get rid of that klugy cache for
Florian G. Pflug [EMAIL PROTECTED] writes:
So should we not force synchronous commit if all to-be-deleted files
are temporary? Or is that pushing our luck too much, because it opens
the window of possible file leakage considerably wider?
I think this area is something to be left for later.
Merlin Moncure wrote:
I noticed that enums are not available to be queried as binary through
the protocol. Is this a known issue? Too late to fix for 8.3? This
is kind of a pain, because it forces any query that returns an enum to
return the entire result as text. afaik, enums are the only
Alvaro Herrera [EMAIL PROTECTED] writes:
I'm not sure I follow. Are you suggesting adding a new function,
similar to pg_class_ownercheck, which additionally checks for temp-ness?
No, I was just suggesting adding the check for temp-ness in cluster()
and cluster_rel() where we do
Merlin Moncure [EMAIL PROTECTED] writes:
I noticed that enums are not available to be queried as binary through
the protocol.
What do you think the binary representation ought to be? Copying OIDs
seems pretty useless.
regards, tom lane
---(end
Andrew Dunstan [EMAIL PROTECTED] writes:
Merlin Moncure wrote:
I noticed that enums are not available to be queried as binary through
the protocol.
The trouble is that an enum doesn't have an immutable internal binary value.
I guess we could say that the binary value is the integer offset
What if we just defined the binary format as being identical to the text
format, ie, the enum label? A bit silly but at least it would eliminate
the gotcha that binary I/O fails.
Seems like it would make a lot more sense to the client application that
way too...
-- Korry
On Thu, 2007-08-30 at 00:33 -0400, Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
And I'm quite tempted to not flush the XLOG at all during ABORT, and to
only force synchronous commits if one of the to-be-deleted files is
non-temporary.
+1 on the first, but -1 on the second,
On Thu, 2007-08-30 at 14:14 -0400, Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
So should we not force synchronous commit if all to-be-deleted files
are temporary? Or is that pushing our luck too much, because it opens
the window of possible file leakage considerably wider?
Async Commit is a useful feature, yet it requires some additional
application code to be added to appropriate transactions. That code is
then clearly version dependent, which may not always be desirable.
It would be good if there was a way to make that a DBA-controllable
setting, much the same as
Tom Lane wrote:
What if we just defined the binary format as being identical to the text
format, ie, the enum label? A bit silly but at least it would eliminate
the gotcha that binary I/O fails.
So we should pretty much mimic text_send/text_recv? If so I can probably
get that
Why does the windows installer require a password for the superuser
account, since it's perfectly legitimate not to have a password on
that account? I could see perhaps producing a warning, but making
this a hard requirement seems like overkill.
--
Decibel!, aka Jim Nasby
Simon Riggs [EMAIL PROTECTED] writes:
Perhaps it would be possible to do this
ALTER FUNCTION fubar SET synchronous_commit = off;
So that any invocation of the function would automatically set all of
the appropriate parameters prior to execution.
The problem here is that functions
Simon Riggs wrote:
Async Commit is a useful feature, yet it requires some additional
application code to be added to appropriate transactions. That code is
then clearly version dependent, which may not always be desirable.
It would be good if there was a way to make that a DBA-controllable
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...
It's definitely possible, but it's inconvenient and
Simon Riggs [EMAIL PROTECTED] writes:
-1 to second: If there are any temporary deleted files then it is
because we've done a large sort, hash join etc, so avoiding the sync
makes no difference to the overall response time.
I think you're confused, actually: this is not about temporary sort
Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
-1 to second: If there are any temporary deleted files then it is
because we've done a large sort, hash join etc, so avoiding the sync
makes no difference to the overall response time.
I think you're confused, actually: this is not
Alvaro Herrera [EMAIL PROTECTED] writes:
Why don't we create temp tables in a separate directory, anyway? That
would make it trivially easy to get rid of them during recovery: just
zap all the files in there.
Hmm ... doesn't do anything to fix the problem of file leakage for
crashes when
Tom Lane wrote:
Whether that's common enough to be worth special optimization, I'm
not sure. Your point that the transaction may have been heavyweight
enough that it'd hardly matter is still on-target, you just got there
by the wrong reasoning ;-)
My point is that there is hardly any effort
Joshua D. Drake wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Some committers are using DocBook installations that seem quite lax
about closing tags :-(, so they fail to see this type of breakage.
Yep. What should I upgrade, and to what version?
Joshua D. Drake wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Some committers are using DocBook installations that seem quite lax
about closing tags :-(, so they fail to see this type of breakage.
Yep. What should I upgrade, and to what
Tatsuo Ishii wrote:
I figured out how to make my toolchain warn about missing tags like
newer tool chains. My openjade needs the -wfully-tagged warning. I
added it to sgml/Makefile.
--
Bruce Momjian [EMAIL PROTECTED] http://momjian.us
EnterpriseDB
Tatsuo Ishii wrote
Can someone please fix this?
openjade -wall -wno-unused-param -wno-empty -wfully-tagged -D . -c
/usr/share/sgml/docbook/dsssl-stylesheets/catalog -d stylesheet.dsl -i
output-html -t sgml postgres.sgml
openjade:bookindex.sgml:2731:0:E: character data is not allowed here
Tatsuo Ishii wrote:
I figured out how to make my toolchain warn about missing tags like
newer tool chains. My openjade needs the -wfully-tagged warning. I
added it to sgml/Makefile.
--
Bruce Momjian [EMAIL PROTECTED] http://momjian.us
EnterpriseDB
Andrew Dunstan [EMAIL PROTECTED] writes:
Tatsuo Ishii wrote
Can someone please fix this?
It's working for me
On Fedora Core 6's sgml toolchain, HEAD builds but un-commenting those
two index entries fails, just as Tatsuo says.
I'm no expert in this, but looking at the complained-of
66 matches
Mail list logo
