[BUGS] LIKE 'bla%'
Henrik Steffen ([EMAIL PROTECTED]) reports a bug with a severity of 2 The lower the number the more severe it is. Short Description LIKE 'bla%' Long Description I just wanted to delete a record from a table, using DELETE FROM MYTABLE WHERE NAME LIKE 'Ant%'; knowing that there existed only one record with 'Anton' as name. However, the code above delivered 'DELETE 0' Then I did this: DELETE FROM MYTABLE WHERE NAME LIKE 'Anto%'; which gave 'DELETE 1' Isn't this strange? Sample Code DELETE FROM MYTABLE WHERE NAME LIKE 'Ant%'; <=> DELETE FROM MYTABLE WHERE NAME LIKE 'Anto%'; No file was uploaded with this report
[BUGS] PG still fussy to compile on Solaris + GCC, may still need Sun ld
Matt Benjamin ([EMAIL PROTECTED]) reports a bug with a severity of 2 The lower the number the more severe it is. Short Description PG still fussy to compile on Solaris + GCC, may still need Sun ld Long Description I found that on my Solaris 8, Sparc system with GCC and GNU Binutils, there was one major and one minor hassle: 1. PG libs failed to link with GCC + GNU ld -- switching to Sun ld fixed this 2. PG Perl interface Makefile.PL produced Sun compiler options for compiling PG.c, e.g., "-KPIC", etc. Easy to fix, but required hacking to get "make install" to run to completion. Sample Code No file was uploaded with this report
Re: [BUGS] LIKE 'bla%'
[EMAIL PROTECTED] writes: > DELETE FROM MYTABLE WHERE NAME LIKE 'Ant%'; > knowing that there existed only one record with 'Anton' as name. > However, the code above delivered 'DELETE 0' > DELETE FROM MYTABLE WHERE NAME LIKE 'Anto%'; > which gave 'DELETE 1' > Isn't this strange? Yup. What PG version are you using, and are you running it with a non-English LOCALE setting? Is there an index on the NAME column? I suspect you are running into another variant of the problem we've had for a long time concerning how to derive upper and lower index boundes for a LIKE string. In ASCII locale it's pretty easy: name >= 'Ant' AND name < 'Anu' can be used to scan the index for all entries that might match the given LIKE pattern. But in non-ASCII locales with complicated collation rules that method tends to fail. See the pgsql-hackers mailing lists; latest go-round was thread Sigh, LIKE indexing is *still* broken in foreign locales in early June 2000. At the moment I don't think we know a bulletproof solution, other than not using indexes for LIKE, which won't make people happy either ... regards, tom lane
Re: [BUGS] PG still fussy to compile on Solaris + GCC, may still need Sun ld
[EMAIL PROTECTED] writes: > 2. PG Perl interface Makefile.PL produced Sun compiler options for > compiling PG.c, e.g., "-KPIC", etc. We deliberately try to build the Perl interface with the same compiler and options that the local Perl installation claims it was built with, regardless of what you are building Postgres with. Experience so far on multi-compiler platforms is that it's much more likely that the interface will actually work if built that way (remember it's going to link into the Perl executable, not into Postgres). Did it not work if you just let the makefile do what it wanted? regards, tom lane
[BUGS] unique/references not honored when inheriting tables
Helge Bahmann ([EMAIL PROTECTED]) reports a bug with a severity of 4 The lower the number the more severe it is. Short Description unique/references not honored when inheriting tables Long Description If a table inherits fields carrying the "references" or "unique" constraint, they are not honoured but silently dropped. It is necessary to manually create the triggers/indices. It would be nice if it were possible to create an index across a table and all sub-tables. Sample Code CREATE TABLE foo(id int unique) CREATE TABLE bar() INHERITS (foo) INSERT INTO bar VALUES(1) INSERT INTO bar VALUES(1) No file was uploaded with this report
Re: [BUGS] PG still fussy to compile on Solaris + GCC, may still need Sun ld
Matt Benjamin <[EMAIL PROTECTED]> writes: > What do you mean, "do what it wanted?" The configure script produced a > setup that would not build a perl interface, and the error was related to > SunWS compiler options. > Sounds like half my problem was using the Perl5 that Sun provides with > Solaris 8. . . Urgh, could be. If you'd built and installed Perl yourself, it'd be a pretty good bet that it'd report a compiler name and switches that would actually work on your box. If you're using a vendor-supplied Perl then I could see how there might be a problem: perhaps they used a compiler different from the one you have. Not sure what we could/should do about this. We used to try to force the perl5 interface to be built with the same compiler/switches used for Postgres. Our current behavior (ie, just accepting MakeMaker's stored recollection of the Perl build setup) was chosen after getting reports that that didn't work either, on machines where there was actually some material difference. Seems like we lose either way, just on different machines... > The larger problem was of linking the PG libs. I had a copy of Sun ld > around, but, since this (somehow, like the compiler) doesn't come with the > OS, it is a safe bet that a fair number of folks won't have it. I'd argue that that means GNU ld is broken on your platform, and you ought to be complaining to the bintools people about it. Postgres doesn't do anything particularly out-of-the-ordinary as far as the linker is concerned. regards, tom lane
