Hi,
I needed to apply this patch in order for tsearch2 to build here. This
is a VPATH build, so maybe it's a reason why it's not a common test
scenario. The changes itself also seem sound to me, at least as far as
I understand our makefile structure.
Please consider applying this to 8.1 (or
[Resend, this time with the patch attached]
Hi,
I needed to apply this patch in order for tsearch2 to build here. This
is a VPATH build, so maybe it's a reason why it's not a common test
scenario. The changes itself also seem sound to me, at least as far as
I understand our makefile structure.
Hi!
I don't see a patch :)
Alvaro Herrera wrote:
Hi,
I needed to apply this patch in order for tsearch2 to build here. This
is a VPATH build, so maybe it's a reason why it's not a common test
scenario. The changes itself also seem sound to me, at least as far as
I understand our makefile
As I can see, this patch already apllyed at 18 Oct:
% grep subdir */Makefile
ispell/Makefile:subdir = contrib/tsearch2/ispell
snowball/Makefile:subdir = contrib/tsearch2/snowball
wordparser/Makefile:subdir = contrib/tsearch2/wordparser
CVS HEAD
Alvaro Herrera wrote:
[Resend, this time with the
Hi,
I just found out that tcop/dest.h is included in executor/spi.h, and it
contains many things that aren't needed for compiling SPI programs/
libraries. By way of example I compiled the whole of contrib with the
attached patch and it works fine. Notice that the only thing I'm doing
is taking
Teodor Sigaev wrote:
As I can see, this patch already apllyed at 18 Oct:
% grep subdir */Makefile
ispell/Makefile:subdir = contrib/tsearch2/ispell
snowball/Makefile:subdir = contrib/tsearch2/snowball
wordparser/Makefile:subdir = contrib/tsearch2/wordparser
Dohh, you are right. Sorry for the
Alvaro Herrera said:
Hi,
(It also allows PL/php to compile without having to patch
PHP nor PostgreSQL sources).
That will make some people I know happy ;-)
cheers
andrew
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Andrew Dunstan wrote:
Alvaro Herrera said:
Hi,
(It also allows PL/php to compile without having to patch
PHP nor PostgreSQL sources).
That will make some people I know happy ;-)
Yeah -- the current PL/php build system is a crock (not sure what that
is, but it sounds nice and it
Alvaro Herrera [EMAIL PROTECTED] writes:
So instead of changing the names of the CommandDest enum, I'm hiding it
from external view.
I thought renaming them was a better idea, actually. A whole separate
include file to have one forward typedef seems pretty silly. Nor am I
convinced that you
Alvaro Herrera [EMAIL PROTECTED] writes:
I needed to apply this patch in order for tsearch2 to build here.
I fixed that some weeks ago ... how old a version are you looking at?
regards, tom lane
---(end of broadcast)---
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
So instead of changing the names of the CommandDest enum, I'm hiding it
from external view.
I thought renaming them was a better idea, actually. A whole separate
include file to have one forward typedef seems pretty silly. Nor am
Bruce Momjian wrote:
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
So instead of changing the names of the CommandDest enum, I'm hiding it
from external view.
I thought renaming them was a better idea, actually. A whole separate
include file to have one forward typedef
Tom Lane wrote:
I thought renaming them was a better idea, actually.
Here is a patch for that. I will apply this to HEAD later today.
--
Alvaro Herrera Valdivia, Chile ICBM: S 39º 49' 17.7, W 73º 14' 26.8
The eagle never lost so much time, as
when he submitted to learn of the crow.
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
I thought renaming them was a better idea, actually.
Here is a patch for that. I will apply this to HEAD later today.
Looks ok in a quick eyeball pass.
regards, tom lane
---(end of
On Tue, 2005-11-01 at 17:55 -0500, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
FWIW, most databases I've used limit NUMERIC to 38 digits, presumably to
fit length info into 1 or 2 bytes. So there's something to be said for a
small numeric type that has less overhead and a large
Simon Riggs [EMAIL PROTECTED] writes:
On Tue, 2005-11-01 at 17:55 -0500, Tom Lane wrote:
I don't think it'd be worth having 2 types. Remember that the weight is
measured in base-10k digits. Suppose for instance
sign1 bit
weight 7 bits (-64 .. +63)
dscale
On Wed, 2005-11-02 at 13:46 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Tue, 2005-11-01 at 17:55 -0500, Tom Lane wrote:
I don't think it'd be worth having 2 types. Remember that the weight is
measured in base-10k digits. Suppose for instance
sign1 bit
On Tue, 2005-11-01 at 18:19 -0500, Neil Conway wrote:
On Mon, 2005-31-10 at 22:41 +, Simon Riggs wrote:
I believe this is now complete and ready for application.
Comments:
- INSERT, UPDATE, etc. should be marked with command/, unless xref/
would be more appropriate
- The names of
Simon Riggs [EMAIL PROTECTED] writes:
I wasn't trying to claim the bit assignment made sense. My point was
that the work to mangle the two fields together to make it make sense
looked like it would take more CPU (since the standard representation of
signed integers is different for +ve and -ve
We haven't seen any agreement emerge as to what is causing AIX 5.3 ML3
to fail to successfully build the release candidates.
However, a patch has emerged (thanks, Seneca!) that does allow it to
work, and which I'd expect to be portable (better still!).
We are still actively pursuing why it
On Wed, 2005-11-02 at 15:09 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I wasn't trying to claim the bit assignment made sense. My point was
that the work to mangle the two fields together to make it make sense
looked like it would take more CPU (since the standard
On Wed, 2005-11-02 at 15:09 -0500, Tom Lane wrote:
[ thinks for a moment... ] Actually, neither proposal is going to get
off the ground, because the parser's handling of numeric constants is
predicated on the assumption that type NUMERIC can handle any valid
value of FLOAT8, and so we can
Simon Riggs [EMAIL PROTECTED] writes:
It seems straightforward enough to put in an additional test, similar to
the ones already there so that if its too big for a decimal we make it a
float straight away - only a float can be that big in that case. After
that I can't really see what the
On Wed, Nov 02, 2005 at 06:12:37PM -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
It seems straightforward enough to put in an additional test, similar to
the ones already there so that if its too big for a decimal we make it a
float straight away - only a float can be that
[patches removed]
Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
It seems straightforward enough to put in an additional test, similar to
the ones already there so that if its too big for a decimal we make it a
float straight away - only a float can be that big in that case. After
On Wed, 2005-02-11 at 19:55 +, Simon Riggs wrote:
Trying to identify which bit of advice you refer to I put some
comments in based upon feedback from the beta on specific queries that
were not optimised the same as non-inherited tables.
ISTM that query optimization *always* works
Andrew Dunstan [EMAIL PROTECTED] writes:
Could someone please quantify how much bang we might get for what seems
like quite a lot of bucks?
I appreciate the need for speed, but the saving here strikes me as
marginal at best, unless my instincts are all wrong (quite possible)
Two bytes per
Marko Kreen marko@l-t.ee writes:
Few small things:
[ snip ]
Applied, thanks.
I also fixed a few small grammatical problems in the text.
regards, tom lane
---(end of broadcast)---
TIP 1: if posting/reading through Usenet,
28 matches
Mail list logo
