This was fixed in 7.0.1.
> Sorry for a downer on an excellent piece of software.
>
> --
> Darren Steven
> Applications Specialist
> Networking Tasmania
> Telstra Australia
> Ph.1800 813 302
>
>
> If PostgreSQL failed to compile on your computer or you found a bug that
> is likely to be specif
Tom Vijlbrief, Tom Lane added some of your patches to 7.0. Do you have
anything new for 7.1? I know you were still working on it when we
entered beta.
>
> POSTGRESQL BUG REPORT TEMPLATE
> =
Can someone comment on this patch?
>
>
> POSTGRESQL BUG REPORT TEMPLATE
>
>
>
>
> Your name : Berna
Bruce Momjian <[EMAIL PROTECTED]> writes:
> That was my guess, though his changes were s_lock related. Seems that is
> an Alpha mess too.
Yes, it sounds like we will need some help from a certified Alpha guru
to make spinlock code that works reliably on multi-CPU Alphas :-(.
Anyone have friends
That was my guess, though his changes were s_lock related. Seems that is
an Alpha mess too.
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I am unsure how to address this NetBSD/alpha patch.
>
> I'd say leave it out for now. After I finish the fmgr revisions we
> ought to have a better shot a
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am unsure how to address this NetBSD/alpha patch.
I'd say leave it out for now. After I finish the fmgr revisions we
ought to have a better shot at porting to Alphas. I know most of
Ryan K's Linux/Alpha patches will go away with that.
I am only fif
I am unsure how to address this NetBSD/alpha patch.
> Here are minimal patches to get 7.0 beta 3 limping along on NetBSD/alpha
> release 1.4.1.
>
> There are lots of problems with the oid handling, and I can't get it
> to successfully even begin to do a make runcheck, make runtest, or
> make b
Cool. Thanks, Tom.
> "Rick Smith" <[EMAIL PROTECTED]> writes:
> >PostgreSQL version (example: PostgreSQL-6.5.3) :PostgreSQL-6.5.3
>
> > ERROR: ExecSubPlan: null value returned by expression subselect
>
> 6.5 and old
"Rick Smith" <[EMAIL PROTECTED]> writes:
>PostgreSQL version (example: PostgreSQL-6.5.3) :PostgreSQL-6.5.3
> ERROR: ExecSubPlan: null value returned by expression subselect
6.5 and older don't cope with sub-selects r
POSTGRESQL BUG REPORT TEMPLATE
Your name :Richard Smith
Your email address : [EMAIL P
Seems MOVE 0 moves to the end of the cursor. The FETCH manual says:
SQL92 allows one to repetatively retrieve the cur-
sor at its "current position" using the syntax
FETCH RELATIVE 0 FROM cursor
Postgres does not currently support thi
> "Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> > If I remember correctly *move 0* means *move all* in the
> > implementation of cursor.
>
> It does (I looked at it before).
>
> > I don't know if it's the spec or not.
>
> As best I can tell from SQL92, FETCH RELATIVE 0 implies no movement
> (r
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I just sent off an email stating that MOVE 0 goes to the end, and that
> > the FETCH manual page says:
>
> > Postgres does not currently support this notion; in
> > fact the value zero is reserved to indicate that
> >
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> We may have documented the behavior, but that doesn't make it right ;-)
>> If someone were to submit a patch to change MOVE 0 into a no-op
>> (without breaking MOVE ALL of course), I'd vote to apply it.
> If we do that, how does one move to the end of
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> We may have documented the behavior, but that doesn't make it right ;-)
> >> If someone were to submit a patch to change MOVE 0 into a no-op
> >> (without breaking MOVE ALL of course), I'd vote to apply it.
>
> > If we do that, how does one move to
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I just sent off an email stating that MOVE 0 goes to the end, and that
> the FETCH manual page says:
> Postgres does not currently support this notion; in
> fact the value zero is reserved to indicate that
>
"Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> If I remember correctly *move 0* means *move all* in the
> implementation of cursor.
It does (I looked at it before).
> I don't know if it's the spec or not.
As best I can tell from SQL92, FETCH RELATIVE 0 implies no movement
(refetch same row). M
17 matches
Mail list logo
