Hello,
I would be happy if it is possible to apply this patch to include/utils/datetime.h
to target NetWare.
On NetWare TIMEZONE_GLOBAL is _timezone.
best wishes.
Ulrich Neumann
Novell Worldwide Developer Support
begin 666 nw.diff
M,C`Y+#(Q,6,R,#D-"CP@(VEF9&5F(%]?0UE'5TE.7U\-"CP@(V1E9FEN92!4
[EMAIL PROTECTED] ("Luis Alberto Amigo Navarro") wrote in message
news:<005901c1d17a$4d7b0e10$[EMAIL PROTECTED]>...
> >
> > cc-1070 cc: ERROR File = xact.c, Line = 587
> > The indicated type is incomplete.
> >
> > struct timeval delay;
>
> struct timeval must be defined
Neil Conway <[EMAIL PROTECTED]> writes:
> I can see 1 potential problem: there is a race condition in the "detect
> an overrun" logic.
Only if you do it that way :-(. Take another look at the SI messaging
logic: it will *not* lose overrun notifications.
regards, tom lane
On Sat, 2002-03-23 at 12:46, Tom Lane wrote:
> Also, the notion that the NOTIFY mechanism can't be lossy misses the
> fact that you've got a perfectly good non-lossy mechanism at hand
> already: user tables. The traditional way of using NOTIFY has been
> to stick the important data into tables an
Greg Copeland <[EMAIL PROTECTED]> writes:
> What if we used a combination of the two approaches? That is, when an
> overflow occurs, overflow into a table?
I think this is a really bad idea.
The major problem with it is that the overflow path would be complex,
infrequently exercised, and theref
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> I have throught of at least two problems with changing nullability. The
> first is primary keys. I have to prevent people setting a column involved
> in a PK to null, right?
Probably so.
> The second is DOMAINs - what if they change a NOT N
What if we used a combination of the two approaches? That is, when an
overflow occurs, overflow into a table? That way, nothing is lost and
spurious random events don't have to occur. That way, things are faster
when overflows are not occurring. When the system gets too far behind,
it simply o
> You could possibly make it work if you were willing to include the word
> TYPE when trying to respecify column type:
>
> ALTER TABLE blah ALTER [COLUMN] col [TYPE int4] [NOT NULL] [DEFAULT 32];
>
> Also I agree with Fernando that trying to make the word COLUMN optional
> is likely to lead to con
