Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> To insert a tab using readline you can press ESC followed by TAB.
...or ^V followed by TAB, as per age-old tradition. :-)
-tih
--
Don't ascribe to stupidity what can be adequately explained by ignorance.
---(end of broadca
list them here doesn't
# matter.)
! SHLIB_LINK += $(filter -lcrypt -ldes -lkrb -lcom_err -lcrypto -lk5crypto -lkrb5
-lssl -lsocket -lnsl -lresolv -lintl -lutil -lasn1 -lroken, $(LIBS))
all: all-lib
--
Tom Ivar Helbekkmo, Senior System Administrator, EUnet
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> But since the construct is not allowed (or useless), why would
> anyone feel they need to use it?
Because it isn't entirely useless, actually. I agree that no
programmer in his right mind would write, by hand, a comparison
involving NULL, knowing th
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> Actually I am not sure whether the column = NULL syntax is even
> defined or allowed in SQL92
I've just checked, by reading the relevant paragraphs and studying the
BNF, and the standard says that any comparison of the form X
Y is unknown if
Mike Mascari <[EMAIL PROTECTED]> writes:
> The best solution would be to have the ODBC translate instances of '=
> NULL' into IS NULL before submitting the query to PostgreSQL. I'm
> sure this is how other vendors, like Oracle handle the issue. Well,
> probably sure... :-)
That's the intell
Stephan Szabo <[EMAIL PROTECTED]> writes:
> That's the nature of the hack we're talking about. It's a grammar
> level hack to turn a specific sequence of tokens (= NULL) into IS
> NULL due to a client's generated queries.
Aha! Sorry -- I jumped in late in the discussion without checking
back t
Tom Lane <[EMAIL PROTECTED]> writes:
> A compromise answer might be to offer a SET variable that selects the
> Microsoft-compatible misimplementation. Would that fly?
I'd say that's the best way to handle stuff like this. If you
implement something that breaks the standard, to be compatible wi
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> Thus it could be, that NULL in "where column = NULL" is not defined
> to have a special meaning according to SQL92.
The way I interpret Celko's interpretation of SQL92, that specific
construct has a meaning; it evaluates to UNKNOWN, thus not
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Here is a small list of big TODO items. I was wondering which ones
> people were thinking about for 7.2?
A friend of mine wants to use PostgreSQL instead of Oracle for a large
application, but has run into a snag when speed comparisons looked
good unt
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> Actually I am not sure whether the column = NULL syntax is even defined
> or allowed in SQL92 (e.g. Informix interprets the NULL as column name in
> this context and errs out).
I don't have the standard handy, but I do have Joe Celko's book,
Tom Lane <[EMAIL PROTECTED]> writes:
> > I think this is indisputably a bug in (some versions of) NetBSD.
>
> I forgot to mention a possible contributing factor: the files involved
> were NFS-mounted, in the case I was looking at. So this may be an NFS
> problem more than a NetBSD problem. Any
matthew green <[EMAIL PROTECTED]> writes:
> i also believe the `Bad address' errors were caused when the test
> was run in an NFS mounted directory.
You may have something, there. My test run on the VAX was over NFS.
I set up NetBSD on a VAX specifically to test PostgreSQL 7.1, but I
didn't hav
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> On such a platform it would hardly be possible to detect anything with any
> reliably. A linker that links a program "succesfully" while the program
> really needs more libraries to be runnable isn't very useful.
You're right, of course -- it's a b
Giles Lean <[EMAIL PROTECTED]> writes:
> It is still necessary to add -ltermcap after -ledit in
> src/Makefile.global to have functional history editing in psql.
This is a weakness in the configure script: it goes through a loop
where it tries to link a program that calls readline() with, in ord
Tom Lane <[EMAIL PROTECTED]> writes:
> >> CREATE INDEX hash_i4_index ON hash_i4_heap USING hash (random int4_ops);
> >> + ERROR: cannot read block 3 of hash_i4_index: Bad address
>
> "Bad address"? That seems pretty bizarre.
This is obviously something that shows up on _some_ NetBSD platforms
Tom Ivar Helbekkmo <[EMAIL PROTECTED]> writes:
> > We need some NetBSD folks to speak up!
>
> I've once again got a VAX that should be able to run PostgreSQL on
> NetBSD/vax, so I hope to be able to help revitalize that port soon...
It still works. RC1 configures, c
I wrote:
> > NetBSD Sparc 7.0 2000-04-13, Tom I. Helbekkmo
>
> Fetching the latest source kit now -- hope to have regression tests
> run and a report back to you within a day or two.
Hmm. No go here: everything looks peachy until I've started the
postmaster, and attempt to connect to it:
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> NetBSD Sparc 7.0 2000-04-13, Tom I. Helbekkmo
Fetching the latest source kit now -- hope to have regression tests
run and a report back to you within a day or two.
> We need some NetBSD folks to speak up!
I've once again got a VAX that should
18 matches
Mail list logo
