> 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.
Without a context diff, it is not entirely clear to me what *exactly*
the patch is doing since I'm working with an already-patched datetime.h.
How
I've got patches to enable storage of date/time values as integers
rather than as floating point numbers, as discussed earlier. 64-bit
integers are (afaik) not available on every platform we want to support,
and there *may* be a performance difference depending on the processor
and compiler involv
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> 1) For the ./configure command line option, does
> --enable-integer-datetimes seem OK, or could someone suggest a better
> choice? --enable-integer-datetimes is a longer string than any of the
> other options, so a less wordy possibility may be better.
> I'd suggest --enable-bigint-datetimes, or possibly
> --enable-int8-datetimes, to make it clearer that 64-bit-int support
> is needed.
Hmm. The *feature* it is enabling is "consistant precision through the
range of allowed values". I'd rather move in the direction of
qualitative description, tha
for whom? you? robot?
On Sun, 24 Mar 2002, Oleg Bartunov wrote:
> Marc,
>
> something is strange. No messages from any pg mailing lists !
> Please, check subscribers list.
>
> Oleg
>
> On Tue, 19 Mar 2002, Marc G. Fournier wrote:
>
> >
> > do you know if any of the other lists are missin
I was browsing through SQL92 and I noticed this, when discussing the
CREATE VIEW syntax:
"5) Any that is specified in the shall
be different from the of any ."
( is the defintion of the view. This basically says
that you're not allowed to create views on temp tables.)
Currently, PostgreSQL a
Neil Conway wrote:
> I was browsing through SQL92 and I noticed this, when discussing the
> CREATE VIEW syntax:
>
> "5) Any that is specified in the shall
> be different from the of any declaration>."
>
> ( is the defintion of the view. This basically says
> that you're not allowed to create
Thomas Lockhart writes:
> I've got patches to enable storage of date/time values as integers
> rather than as floating point numbers, as discussed earlier.
I'd like to know first what the overall plan for this feature is. If it
is to make the date/time values "better" all around, i.e., you get
> > I've got patches to enable storage of date/time values as integers
> > rather than as floating point numbers, as discussed earlier.
> I'd like to know first what the overall plan for this feature is.
My feeling is that the int64 implementation will be "better". But I
*don't* know how many pla
> OK, how about:
>
> SET CONSTRAINT NOT NULL
>
> or
>
> DROP CONSTRAINT NOT NULL
>
> or simply:
>
> SET/DROP NOT NULL
>
> I think the problem with trying to get it look like CREATE TABLE is that
> the plain NULL parameter to CREATE TABLE is meaningless and probably
> should never
Hi Thomas,
thanks for your response.
Your assumption is correct. All I need is what you described:
#ifdef __CYGWIN__
to
#if defined(__CYGWIN__) || defined(N_PLAT_NLM)
Sorry that the patchfile didn't include the context. I will make sure that this
doesn't happen any more.
Ulrich Neumann
Novell W
> ALTER TABLE blah ALTER [COLUMN] col SET NOT NULL;
>
> and
>
> ALTER TABLE blah ALTER [COLUMN] col DROP NOT NULL;
>
> This is synchronous with the SET/DROP default stuff and is
> extensible in the
> future to fit in with column type changing.
>
> Of course, it can always be changed in the parser
Neil Conway <[EMAIL PROTECTED]> writes:
> Currently, PostgreSQL allows this -- when the session ends and the temp
> table is dropped, an subsequent queries on the view fail. Is this the
> optimal behavior?
Well, I think it's better than refusing views on temp tables, as the
spec would have us do.
13 matches
Mail list logo
