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.
> 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
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
> 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
> > 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
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
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
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
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'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
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'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
> 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
13 matches
Mail list logo
