> After failing to make Itanium competitive, Intel is now downplaying
> 64-bit CPU's. Of course, they didn't think that until Itanium failed.
> Here is the slashdot story:
> http://slashdot.org/article.pl?sid=03/02/23/2050237&mode=nested&tid=118
>
> Seems AMD's hammer is going to be the popular
On Mon, 17 Feb 2003 09:51:54 +0800, "Christopher Kings-Lynne"
<[EMAIL PROTECTED]> wrote:
>Strategy three:
>
>begin;
>lock table in exclusive mode;
>update row;
>if (no rows affected) insert row;
>commit;
>
>Problem - Works, but this table needs high concurrency.
Chris,
distributing congestion mig
After failing to make Itanium competitive, Intel is now downplaying
64-bit CPU's. Of course, they didn't think that until Itanium failed.
Here is the slashdot story:
http://slashdot.org/article.pl?sid=03/02/23/2050237&mode=nested&tid=118
Seems AMD's hammer is going to be the popular 64
On Mon, Feb 24, 2003 at 07:53:05PM +, Darko Prenosil wrote:
> I need two answers I did not find in documentation :
>
> How can I get exact number of rows in DECLARED CURSOR ?
> OK, I can FETCH until NULL, but this does not fits my needs !
You need to move to the end of the cursor. When
Tom Lane kirjutas E, 24.02.2003 kell 19:30:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Hey, I don't want to take your ILIKE away. But at the time it was added
> > the claim was that it was for compatibility and now we learn that that was
> > wrong.
This _is_ a compatibility feature, just
On Sunday 23 February 2003 20:52, Dave Page wrote:
> > -Original Message-
> > From: Ian Barwick [mailto:[EMAIL PROTECTED]
> >
> > Would it be possible to modify the new docs to provide
> > similar functionality? E.g. something like
>
> http://www.postgresql.org/docs/view.php?version=current
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Josh Berkus writes:
>> 4) It's just as indexible (or not indexable) as regexp comparisons, and easier
>> to understand for users from the Microsoft world than regexp.
> ILIKE is not indexible at all.
You are arguing from a false premise.
regression=
Peter,
> > 4) It's just as indexible (or not indexable) as regexp comparisons, and
> > easier to understand for users from the Microsoft world than regexp.
>
> ILIKE is not indexible at all. Other forms of pattern comparisons are at
> least indexible sometimes.
And how is ~* indexable?
--
Jo
Josh Berkus writes:
> 4) It's just as indexible (or not indexable) as regexp comparisons, and easier
> to understand for users from the Microsoft world than regexp.
ILIKE is not indexible at all. Other forms of pattern comparisons are at
least indexible sometimes.
--
Peter Eisentraut [EMAIL
In the old days, when every function of the form foo(bar) was a cast from
bar to foo, and if foo and bar happened to be binary compatible, the
system short-circuited this function call to do a "zero-effort" cast.
This logic still exists, but since in general casts are controlled
through pg_cast no
This example in User's Guide section 7.2 doesn't work anymore at all:
tgl=> select @ text '-4.5' as "abs";
abs
-
4.5
(1 row)
What really happens is this:
=> select @ text '-4.5' as "abs";
ERROR: Unable to identify a prefix operator '@' for type 'text'
You may need to add parenthes
I need two answers I did not find in documentation :
How can I get exact number of rows in DECLARED CURSOR ?
OK, I can FETCH until NULL, but this does not fits my needs !
How can I get information is TRANSACTION already started ?
(TRANSACTION LEVEL)
The interface I'm using is libpq.
Four Reasons to use ILIKE, which have nothing to do with mSQL:
1) It's faster to type than most analagous regexp comparisons, and much faster
than comparing two LOWERs or two UPPERS.
2) It's a great operator for comparing two text variables or columns of small
tables where you don't want to wor
Given that the direction of the spec seems to be headed towards the
desired syntax, can we put this on the TODO list?
Dave
On Thu, 2003-02-20 at 11:49, Dave Cramer wrote:
> Scott,
>
> I can't find page 858 in that document, is it the right one?
>
> also the link s/b ?
>
> ftp://ftp.sqlstandar
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Hey, I don't want to take your ILIKE away. But at the time it was added
> the claim was that it was for compatibility and now we learn that that was
> wrong. That is something to make people aware of, for example in the
> documentation.
It already d
Vince Vielhaber writes:
> > It's never too late for new users to reconsider. It's also never too late
> > to change your application of performance is not satisfactory.
>
> And if performance is satisfactory?
Hey, I don't want to take your ILIKE away. But at the time it was added
the claim was
User's Guide section 7.2, example 7-1, claims that
SELECT 2 ^ 3 AS "Exp";
will be equivalent, after type resolution, to
SELECT CAST(2 AS double precision) ^ CAST(3 AS double precision) AS "Exp";
(which is true) or
SELECT 2.0 ^ 3.0 AS "Exp";
which is not true, since 2.0 and 3.0 are nowadays of
On Sat, 22 Feb 2003, Peter Eisentraut wrote:
> AFAICT, ILIKE cannot use an index. So why does ILIKE even exist, when
> lower(expr) LIKE 'foo' provides a solution that can use an index and is
> more standard, too?
I would guess because for lower(expr) to work you need to make an index on
it. Si
On Mon, 2003-02-24 at 07:22, Christoph Haller wrote:
> I've noticed subsequent executions of the same insert command are slow.
> I've searched the list archives for this matter and found several
> entries
> related, including suggestions how to speed up.
> The standard answer from the core team is,
Hi all,
I was just wondering.The patches for making ecpg thread safe that were
floating around few days back, are they going to make in any near future
releases?
I am badly bitten by libpq as code i my multithreaded app. is growing
steadily. I find myself making stupid mistakes every now and t
Vince Vielhaber <[EMAIL PROTECTED]> writes:
> On Tue, 25 Feb 2003, Justin Clift wrote:
>> As an alternative to _removing_ it, would a feasible idea be to
>> transparently alias it to something else, say a specific type of regex
>> query or something?
> Why screw with it for the sake of screwing wi
Vince Vielhaber wrote:
Why screw with it for the sake of screwing with it?
Hmmm, good point. "If it aint broke" ?
Regards and best wishes,
Justin Clift
Vince.
--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to
On Tue, 25 Feb 2003, Justin Clift wrote:
> Peter Eisentraut wrote:
> > Tom Lane writes:
> >
> >>My feeling too. Whatever you may think of its usefulness, it's been a
> >>documented feature since 7.1. It's a bit late to reconsider.
> >
> > It's never too late for new users to reconsider. It's al
Christoph Haller <[EMAIL PROTECTED]> writes:
> Taken from the Reference Manual
> [REPEATED] INSERT INTO ...
> The key word REPEATED directs INGRES to encode the INSERT and save its
> execution plan when it is first executed. This encoding can account for
> significant performance improvements on s
Peter Eisentraut wrote:
Tom Lane writes:
My feeling too. Whatever you may think of its usefulness, it's been a
documented feature since 7.1. It's a bit late to reconsider.
It's never too late for new users to reconsider. It's also never too late
to change your application of performance is not
On Mon, 24 Feb 2003, Peter Eisentraut wrote:
> Tom Lane writes:
>
> > My feeling too. Whatever you may think of its usefulness, it's been a
> > documented feature since 7.1. It's a bit late to reconsider.
>
> It's never too late for new users to reconsider. It's also never too late
> to change
Josh Berkus writes:
> - Some other databases support ILIKE and it makes porting easier.
Which database would that be?
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgr
Tom Lane writes:
> My feeling too. Whatever you may think of its usefulness, it's been a
> documented feature since 7.1. It's a bit late to reconsider.
It's never too late for new users to reconsider. It's also never too late
to change your application of performance is not satisfactory.
--
I've noticed subsequent executions of the same insert command are slow.
I've searched the list archives for this matter and found several
entries
related, including suggestions how to speed up.
The standard answer from the core team is, use COPY.
Sorry, but this is from an application point of vie
On Sun, 2003-02-23 at 23:31, Tom Lane wrote:
> Josh Berkus <[EMAIL PROTECTED]> writes:
> > - Some other databases support ILIKE and it makes porting easier.
>
> Which other ones? I checked our archives and found that when we were
> discussing adding ILIKE, it was claimed that Oracle had it. But
30 matches
Mail list logo
