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 jus
[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 str
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 t
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
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
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 yo
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.
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
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
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)
>>
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
> >>sign
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 , unless
> would be more appropriate
>
> - The names of GUC
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 an
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 breaks
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 p
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
[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 dif
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
Marko Kreen 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, please sen
28 matches
Mail list logo
