Re: [HACKERS] Backslash handling in strings
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 broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Re: AW: Re: [SQL] behavior of ' = NULL' vs. MySQL vs. Stand ards
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 that the truth value of that comparison is required by the standard to be UNKNOWN (i.e. NULL). However, I'm looking at using machine generated SQL code (generated on the fly in an interactive application) to implement a dynamically adapting set of tables, rules/triggers and their supporting stored procedures, and it's just a matter of time before the first = NULL happens to show up in code generated like that. I'd like it to behave according to the standard when that situation occurs, and the standard says that any comparison with NULL, even NULL = NULL, is UNKNOWN. -tih -- The basic difference is this: hackers build things, crackers break them. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: AW: [HACKERS] Re: [SQL] behavior of ' = NULL' vs. MySQL vs. Stand ards
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, Data Databases: Concepts in Practice. He says (in section 8.2, under the heading Multivalued Logic): A NULL cannot be compared to another NULL or to a value with what Dr. Codd called a theta operator and what programmers call a comparison operator (equal, not equal, less than, greater than, and so forth). This results in a three-valued logic, which has an UNKNOWN in addition to TRUE and FALSE. [...] UNKNOWN is a logical value and not the same as a NULL, which is a data value. That is why you have to say X IS [NOT] NULL in SQL and not use X = NULL instead. Theta operators are expressions of the form X comp op Y; when X or Y or both are NULL, theta operators will return an UNKNOWN and not a NULL. He goes on to explain three-valued logic in more detail, showing truth tables according to Jan Lukasiewicz (the inventor of RPN), and says, of SQL-92, that it is comforting to see that [it has] the same truth tables as the three-valued system of Lukasiewicz. Further, he says: SQL-92 added a new predicate of the form search condition IS [NOT] TRUE | FALSE | UNKNOWN which will let you map any combination of three-valued logic to the two Boolean values. A quick test run with psql shows that PostgreSQL does not properly implement three-valued logic: it does not recognize the UNKNOWN keyword alongside TRUE and FALSE, in any situation. It will also return boolean truth values for comparisons with NULL values, using them as real data values in the comparison. Worse (IMHO), this is not consistent: while a test for column = NULL will return rows where that is true, and a test for not column = NULL will return the rest, column NULL returns no rows! This means that the theta operators are not all treated the same way, which is surely wrong! It seems to me that the idea of NULL as an unkown data value and UNKNOWN as the corresponding truth value, combined with the rules for propagation of NULL in mathematical operations, of UNKNOWN in truth operations, and from NULL to UNKNOWN by theta operators, is a very clean, intuitive way of handling these issues. It feels right! :-) -tih -- The basic difference is this: hackers build things, crackers break them. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: AW: AW: [HACKERS] Re: [SQL] behavior of ' = NULL' vs. MySQL vs. S tand ards
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 to TRUE, and the WHERE clause becomes useless, as does any other combination of a theta operator and the explicit constant 'NULL'. This is almost, but not quite, an argument for allowing = NULL for IS NULL. ;-) Does anyone out there have the actual text of the standard? -tih -- The basic difference is this: hackers build things, crackers break them. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: AW: [HACKERS] Re: [SQL] behavior of ' = NULL' vs. MySQL vs. Stand ards
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 to see how it started... OK, I've already said that I like the cleanliness and orthogonality of NULL is a missing data value, UNKNOWN is a missing truth value, both propagate in expressions, comparisons with NULL generate UNKNOWN, and you can use the special comparisons IS [NOT] NULL and IS [NOT] UNKNOWN to get plain, two-valued Boolean truth values out of them. The Microsoft compatibility hack is ugly, and should be either a) removed, b) expanded to include the other comparison operators and documented as a PostgreSQL proprietary extension, or c) made into a special feature that's turned on at will by a SET command. I would applaud a), approve of c), and be dismayed by b). I think adding IS UNKNOWN would probably be trivial (I think the code is basically there in IS NULL.) But if it's implemented, shouldn't the code also differentiate between UNKNOWN and NULL, by not (as now) using the latter to represent the former? Or do I misunderstand how it's handled now? -tih -- The basic difference is this: hackers build things, crackers break them. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: AW: [HACKERS] Re: [SQL] behavior of ' = NULL' vs. MySQL vs. Stand ards
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 comp op Y is unknown if X or Y (or both) is NULL, including the case where NULL is given as an explicit constant. So, SQL92 clearly demands that column = NULL is UNKNOWN, never TRUE or FALSE. -tih -- The basic difference is this: hackers build things, crackers break them. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] 7.2 items
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 until the Oracle folks added a couple of BITMAP indexes. I can't recall seeing any discussion about that here -- are there any plans? -tih -- The basic difference is this: hackers build things, crackers break them. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: [SQL] behavior of ' = NULL' vs. MySQL vs. Standards
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 with arrogant programmers at Microsoft who feel that they are above such things, you're encouraging users to develop bad habits. Better to make them go SET MICROSOFT BUG COMPATIBILITY ON first. To see the effect of leniency in re standards, just try to browse around the web with a browser that rejects incorrect HTML! :-) -tih -- The basic difference is this: hackers build things, crackers break them. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: [SQL] behavior of ' = NULL' vs. MySQL vs. Standards
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... :-) applause That's the intelligent solution, of course. -tih -- The basic difference is this: hackers build things, crackers break them. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: NetBSD Bad address failure (was Re: [HACKERS] Third call for platform testing)
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. Anyone want to try the given test case on NFS-mounted files on other systems? I can verify, that with NetBSD-current on sparc, your test code works the way you want it to on local disk, but fails (in the way you've observed), if the target file is on an NFS-mounted file system. -tih -- The basic difference is this: hackers build things, crackers break them. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [lockhart@alumni.caltech.edu: [HACKERS] Third call for platform testing]
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 have any disk available that it could use, so I went for NFS. -tih -- The basic difference is this: hackers build things, crackers break them. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Re: Call for platforms
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 order, "-lreadline", "-lreadline -ltermcap", "-lreadline -lncurses", "-lreadline -lcurses", "-ledit", "-ledit -ltermcap", "-ledit -lncurses" and "-ledit -lcurses". The first link that succeeds wil determine which libraries are used. However, on some platforms with dynamic libraries, the link will succeed as soon as readline() is present -- but the shared library that contains it doesn't contain a complete specification of all other libraries it needs at run-time (the executable is expected to hold this information), and the program fails at run-time even though it linked without any error message. I don't know how the situation could best be improved, though... -tih -- The basic difference is this: hackers build things, crackers break them. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Re: Call for platforms
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 bug in the linkage loader on the
platform in question. NetBSD/vax has it:
$ uname -a
NetBSD varg.i.eunet.no 1.5T NetBSD 1.5T (VARG) #4: Thu Apr 5 23:38:04 CEST 2001
[EMAIL PROTECTED]:/usr/src/sys/arch/vax/compile/VARG vax
$ cat foo.c
int main (int argc, char **argv) { readline(); }
$ cc -o foo foo.c
/tmp/ccFTO4Mu.o: Undefined symbol `_readline'referenced from text segment
collect2: ld returned 1 exit status
$ cc -o foo foo.c -ledit
$ echo $?
0
$ ./foo
/usr/libexec/ld.so: Undefined symbol "_tputs"in foo:/usr/lib/libedit.so.2.5
$ echo $?
1
$ ldd foo
foo:
-ledit.2 = /usr/lib/libedit.so.2.5 (0x181b000)
-lc.12 = /usr/lib/libc.so.12.74 (0x182d000)
$
-tih
--
The basic difference is this: hackers build things, crackers break them.
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [lockhart@alumni.caltech.edu: [HACKERS] Third call for platform testing]
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. The above was on sparc64, but that same problem is the only one I see in the regression testing on NetBSD/vax that isn't just different floating point (the VAX doesn't have IEEE), different ordering of (unordered) collections or different wording of strerror() output. NetBSD/i386 doesn't have the "Bad address" problem. -tih -- The basic difference is this: hackers build things, crackers break them. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] Re: Call for 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, compiles and runs on my VAX 4000/500
with NetBSD-current -- but the regression tests give a lot of failures
because the VAX doesn't have IEEE math, leading to different rounding
and erroneous assumptions about the limits of floating point values.
I'll be looking at this more closely.
Also, dynamic loading now works on NetBSD/vax, so my old #ifdef for
that in the backend/port/bsd.c file, which has since propagated into
the new *bsd.c files, can go away (actually, I'm suspicious of the
MIPS part of those, too, but I didn't put that in, and I don't have
any MIPS-based machines):
Index: src/backend/port/dynloader/freebsd.c
===
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/port/dynloader/freebsd.c,v
retrieving revision 1.9
diff -c -r1.9 freebsd.c
*** src/backend/port/dynloader/freebsd.c2001/02/10 02:31:26 1.9
--- src/backend/port/dynloader/freebsd.c2001/04/01 08:01:20
***
*** 63,69
void *
BSD44_derived_dlopen(const char *file, int num)
{
! #if defined(__mips__) || (defined(__NetBSD__) defined(__vax__))
sprintf(error_message, "dlopen (%s) not supported", file);
return NULL;
#else
--- 63,69
void *
BSD44_derived_dlopen(const char *file, int num)
{
! #if defined(__mips__)
sprintf(error_message, "dlopen (%s) not supported", file);
return NULL;
#else
***
*** 78,84
void *
BSD44_derived_dlsym(void *handle, const char *name)
{
! #if defined(__mips__) || (defined(__NetBSD__) defined(__vax__))
sprintf(error_message, "dlsym (%s) failed", name);
return NULL;
#else
--- 78,84
void *
BSD44_derived_dlsym(void *handle, const char *name)
{
! #if defined(__mips__)
sprintf(error_message, "dlsym (%s) failed", name);
return NULL;
#else
***
*** 101,107
void
BSD44_derived_dlclose(void *handle)
{
! #if defined(__mips__) || (defined(__NetBSD__) defined(__vax__))
#else
dlclose(handle);
#endif
--- 101,107
void
BSD44_derived_dlclose(void *handle)
{
! #if defined(__mips__)
#else
dlclose(handle);
#endif
Index: src/backend/port/dynloader/netbsd.c
===
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/port/dynloader/netbsd.c,v
retrieving revision 1.3
diff -c -r1.3 netbsd.c
*** src/backend/port/dynloader/netbsd.c 2001/02/10 02:31:26 1.3
--- src/backend/port/dynloader/netbsd.c 2001/04/01 08:01:20
***
*** 63,69
void *
BSD44_derived_dlopen(const char *file, int num)
{
! #if defined(__mips__) || (defined(__NetBSD__) defined(__vax__))
sprintf(error_message, "dlopen (%s) not supported", file);
return NULL;
#else
--- 63,69
void *
BSD44_derived_dlopen(const char *file, int num)
{
! #if defined(__mips__)
sprintf(error_message, "dlopen (%s) not supported", file);
return NULL;
#else
***
*** 78,84
void *
BSD44_derived_dlsym(void *handle, const char *name)
{
! #if defined(__mips__) || (defined(__NetBSD__) defined(__vax__))
sprintf(error_message, "dlsym (%s) failed", name);
return NULL;
#elif defined(__ELF__)
--- 78,84
void *
BSD44_derived_dlsym(void *handle, const char *name)
{
! #if defined(__mips__)
sprintf(error_message, "dlsym (%s) failed", name);
return NULL;
#elif defined(__ELF__)
***
*** 101,107
void
BSD44_derived_dlclose(void *handle)
{
! #if defined(__mips__) || (defined(__NetBSD__) defined(__vax__))
#else
dlclose(handle);
#endif
--- 101,107
void
BSD44_derived_dlclose(void *handle)
{
! #if defined(__mips__)
#else
dlclose(handle);
#endif
Index: src/backend/port/dynloader/openbsd.c
===
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/port/dynloader/openbsd.c,v
retrieving revision 1.3
diff -c -r1.3 openbsd.c
*** src/backend/port/dynloader/openbsd.c2001/02/10 02:31:26 1.3
--- src/backend/port/dynloader/openbsd.c2001/04/01 08:01:20
***
*** 63,69
void *
BSD44_derived_dlopen(const char *file, int num)
{
! #if defined(__mips__) || (defined(__NetBSD__) defined(__vax__))
sprintf(error_message, "dlopen (%s) not supported", file);
return NULL;
#else
--- 63,69
void *
BSD44_derived_dlopen(const char *file, int num)
{
! #if defined(__mips__)
sprintf(error_message, "dlopen (%s) not supported"
[HACKERS] Re: Call for platforms
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 be able to run PostgreSQL on NetBSD/vax, so I hope to be able to help revitalize that port soon... -tih -- The basic difference is this: hackers build things, crackers break them. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
