On Sat, 2006-11-18 at 00:13 +0100, Martijn van Oosterhout wrote:
On Fri, Nov 17, 2006 at 03:53:35PM -0500, Tom Lane wrote:
Having the supporting code in core does not make much of a difference
otherwise from having it in contrib, does it?
Given the nonextensibility of gram.y and
On Sat, 18 Nov 2006, Simon Riggs wrote:
On Sat, 2006-11-18 at 00:13 +0100, Martijn van Oosterhout wrote:
On Fri, Nov 17, 2006 at 03:53:35PM -0500, Tom Lane wrote:
Having the supporting code in core does not make much of a difference
otherwise from having it in contrib, does it?
Given the
Oleg Bartunov wrote:
So, if we'll not touch grammar, are there any issues with tsearch2 in
core ?
Are there any issues with tsearch2 not in core?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 3: Have
-- Forwarded message --
From: jorge alberto [EMAIL PROTECTED]
Date: Nov 17, 2006 2:09 PM
Subject: Re: [HACKERS] Remove contrib version of rtree_gist --- now in core
system ?
To: Tom Lane [EMAIL PROTECTED]
hi !
thanks for writing!
In postgresql version 8.0.9 the rtree_gist
On Wed, 2006-11-15 at 16:38 -0500, Andrew Dunstan wrote:
My little enumkit tool allows you to create enumerations today very
easily, but its values are completely hardcoded. However, the above
trick still works. The downside is that each enumeration type requires a
tiny bit of compilation.
On Fri, Nov 17, 2006 at 11:40:36PM -0500, Tom Lane wrote:
Stephen Harris [EMAIL PROTECTED] writes:
Why not, after calling fork() create a new process group with setsid() and
then instead of killing the recovery thread, kill the whole process group
(-PID rather than PID)? Then every process
Can't keywords share code
the way to do what you want I think is
like this:
foo: bar_or_baz
{ code block }
;
bar_or_baz: bar | baz ;
I'll try that, thanks.
---(end of broadcast)---
TIP 6: explain analyze is your friend
I suggest you to contribute this kind of code to orafce project [1]
Thanks, I'll go play over there for a while.
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
I found it interesting that gram.c and parse.h already supported SYSDATE.
Only after you ran bison ;-). They're derived files.
Well, so much for my conspiracy theory.
Thanks for the bison lesson.
---(end of broadcast)---
TIP 7: You can help
Simon Riggs wrote:
On Wed, 2006-11-15 at 16:38 -0500, Andrew Dunstan wrote:
My little enumkit tool allows you to create enumerations today very
easily, but its values are completely hardcoded. However, the above
trick still works. The downside is that each enumeration type requires a
Hi,
Peter Eisentraut wrote:
Are there any issues with tsearch2 not in core?
I have run into troubles when restoring a dump, especially across
different versions of PostgreSQL and tsearch2. Mainly because pg_ts_*
are not system tables and thus need to be restored or installed separately.
Why should we add this Oraclism to PostgreSQL? I doesn't add any new
feature.
Certainly, this feature falls well within the class of completely
gratuitous proprietary extensions that we typically reject.
I now agree completely. My purpose is to migrate Oracle databases to
Posgres, and I
--- Original Message ---
From: Peter Eisentraut [EMAIL PROTECTED]
To: Jeremy Drake [EMAIL PROTECTED]
Sent: 18/11/06, 07:30:48
Subject: Re: [HACKERS] Proposal: syntax of operation with tsearch's
configuration
Jeremy Drake wrote:
I am currently in the position that my hosting
Peter Eisentraut wrote:
Oleg Bartunov wrote:
So, if we'll not touch grammar, are there any issues with tsearch2 in
core ?
Are there any issues with tsearch2 not in core?
Quite apart from anything else, it really needs documentation of the
standard we give other core features.
I think if a
On Sat, 18 Nov 2006, Andrew Dunstan wrote:
Peter Eisentraut wrote:
Oleg Bartunov wrote:
So, if we'll not touch grammar, are there any issues with tsearch2 in
core ?
Are there any issues with tsearch2 not in core?
Quite apart from anything else, it really needs documentation of the
Dear PG-hackers,
Based on the paper below [1], I ask: is there anyone working on, or already
tried to such native implementation on PostgreSQL? I didn't find anything
related on pgFoundry. There is also a presentation [2] related to the paper.
By Souripriya Das, Eugene Inseok Chong, George
Andrew Dunstan wrote:
Peter Eisentraut wrote:
Oleg Bartunov wrote:
So, if we'll not touch grammar, are there any issues with tsearch2 in
core ?
Are there any issues with tsearch2 not in core?
Quite apart from anything else, it really needs documentation of the
standard we give other
Alvaro Herrera wrote:
Oleg Bartunov wrote:
On Fri, 17 Nov 2006, Andrew Dunstan wrote:
I am also a bit concerned that the names of the proposed objects (parser,
dictionary) don't convey their purpose adequately. Maybe TS_DICTIONARY and
TS_PARSER might be better if we in fact need to name
Hi Gurjeet,
I will look at the pg_advise bug and will send a patch ASAP.
Best,
Kai
Am 15.11.2006 um 15:34 schrieb Gurjeet Singh:
BUGS:
=
.) The SELECTs in the pg_advise are returning wrong results, when
the same index is suggested twice, because of the SUM() aggregates.
.) I doubt that
Rodrigo,
Besides, what are your opinions on the subject?
That I don't understand what they're talking about. What's Ontology in a
database sense? Can you give some examples?
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
---(end of
Matt,
I now agree completely. My purpose is to migrate Oracle databases to
Posgres, and I had thought that Oracle didn't support CURRENT_DATE,
CURRENT_TIMESTAMP, and so on. However, I've just learned otherwise. So,
I think the proper migration process for a production database would be
to
While working on fixing the recently reported hash-index problem,
I was using a test build with a very small RELSEG_SIZE (128K),
so that I could trigger the reported bug with a reasonably small
amount of data. And I started finding some unexpected data corruption.
I eventually reduced it to this
Josh Berkus wrote:
That I don't understand what they're talking about. What's Ontology in a
database sense? Can you give some examples?
You'll need to RTFP , which in all fairness the OP did cite in his posting :
Tom Lane wrote:
While working on fixing the recently reported hash-index problem,
I was using a test build with a very small RELSEG_SIZE (128K),
so that I could trigger the reported bug with a reasonably small
amount of data. And I started finding some unexpected data corruption.
I eventually
On 11/18/06, Rodrigo Hjort [EMAIL PROTECTED] wrote:
Dear PG-hackers,
Based on the paper below [1], I ask: is there anyone working on, or already
tried to such native implementation on PostgreSQL? I didn't find anything
related on pgFoundry. There is also a presentation [2] related to the paper.
Russell Smith [EMAIL PROTECTED] writes:
Tom Lane wrote:
What is happening is that during that 30-second wait, the bgwriter is
dumping out all the dirty pages, and acquiring open file references
to each segment of table foo as it does so. The VACUUM then truncates
foo back to zero size, since
26 matches
Mail list logo
