Re: [GENERAL] Case sensitivity issue
Szabo Zoltan <[EMAIL PROTECTED]> writes: > Use: ILIKE > > > If I am doing a command such as > > select * from Apples where color like '%red%'; > > how do I make it case insensitive? I was trying to solve a similar problem where I wanted an exact match to work in PostgreSQL and MySQL and ended up with: lower(Field) = lower('string') Is there another way that works on both? -- matthew rice <[EMAIL PROTECTED]> starnix inc. tollfree: 1-87-pro-linuxthornhill, ontario, canada http://www.starnix.com professional linux services & products ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] Where do they find the time??? Great Bridge closed now!!!??
peace_flower <"alavoor[AT]"@yahoo.com> writes: > I hope the MySQL team will drop the development and Jump into PostgreSQL > development. Pgsql going to be the only sql server to > run the WORLD ECONOMY smoothly.. There is no time support and develop > two duplicate products!! PostgreSQL is very advanced SQL server > more advanced than mysql. What a coincidence. I was about to say the exact opposite. Obviously, PostgreSQL isn't the one true database and everyone should Jump into MySQL. It is easier to type. I hope your post was meant as a joke because it was hilarious. -- matthew rice <[EMAIL PROTECTED]> starnix inc. tollfree: 1-87-pro-linuxthornhill, ontario, canada http://www.starnix.com professional linux services & products ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[GENERAL] Q: Record Updating/Locking in Web Environments
Hi guys, I'm looking for some advice from someone that has probably done this before. I have a server this is connected to by various client programs (CLI and Web Interface for now). This server is about to have a concept of users as far as the client/server part goes but the server connects to the PostgreSQL database as a specific user. The problem now is how to do record locking when updating information. Providing the user with a record(s) is done in one transaction. There's no difference [yet] of whether they're using that data to edit or read. Sending the data back for updating is done as a second transaction. I could just associate the timestamp of the record with the user's requested data so that if they try to update it and it's been changed out from under them, they get an appropriate error. I could associate a server->PG connection with each use and keep those pooled. I'm assuming that record locks only last for the transaction and are connection centric, not user centric, right? I hate to admit it here but the server is written so that other databases can be used at the backend so, I guess, that could alter the criteria a bit. Any thoughts on this would be most welcome. Regards, -- matthew rice <[EMAIL PROTECTED]> starnix inc. tollfree: 1-87-pro-linuxthornhill, ontario, canada http://www.starnix.com professional linux services & products ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [GENERAL] shared memory settings: SHMMAX and SHMALL
Gregory Bittar <[EMAIL PROTECTED]> writes: > According to my /usr/include/asm/shmparam.h, > SHMMAX (should be) <= (PAGE_SIZE << _SHM_IDX_BITS) = (4096 bytes << 15) > = 128MB. Mine is just: #define SHMMAX 0x200 > I still don't see where to find the PAGE_SIZE value, although 4096 seems > to be a general default out there. man getpagesize or matt@sol:/usr/include[106]% egrep 'define PAGE_S(IZE|HIFT)' */* 2>/dev/null asm/page.h:#define PAGE_SHIFT 12 asm/page.h:#define PAGE_SIZE(1UL << PAGE_SHIFT) linux/a.out.h:#define PAGE_SIZE 0x400 sys/user.h:#define PAGE_SHIFT 12 sys/user.h:#define PAGE_SIZE(1UL << PAGE_SHIFT) Although, 'man postmaster' says that it used 8k (or "whatever BLCKSZ is set to in config.h") for it's shared memory buffers. > Also according to my server's /usr/include/asm/shmparam.h, > SHMALL should be = (1 << (_SHM_IDX_BITS + _SHM_ID_BITS)) = (1 << > (9+15)) = 16. My 2.2.16 kernel has 15 and 7, BTW. > I wonder why some people are setting SHMALL and SHMMAX to the same value > when one is a measurement in pages and the other a measurement in Pure laziness, I'm sure. > bytes. Also, I thought that SHMMAX should be the max allotment in bytes > per application, rather than the max shared by all applications. If I > anticipate 10 postmasters, is it dangerous to set SHMMAX so high? I'm not certain. I just used those numbers for a testing server (I actually only told postmaster to use ~300MB). Are you saying 10 postmasters or 10 backends? Either way, you can set SHMMAX as high as you like. Just don't tell the postmasters to try and use them all. Actually, I just did this: echo 111 >/proc/sys/kernel/shmmax and got: cat /proc/sys/kernel/shmmax -1773790777 Probably not good, long term :) My kernel also wouldn't let me make SHMALL higher than 16M -- matthew rice <[EMAIL PROTECTED]> starnix inc. tollfree: 1-87-pro-linuxthornhill, ontario, canada http://www.starnix.com professional linux services & products ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [GENERAL] Public Database of zip code information
> You mean this one: > http://ftp.census.gov/geo/www/gazetteer/places.html Is there any chance the you (or anyone else) knows a source of this information for Canada? > > Sometime in the past year, someone mentioned a database that > > contained zipcode, lat/long, and city information--does anyone else > > remember this, or should I check into a drug clinic? Who says these are mutually exclusive :) -- matthew rice <[EMAIL PROTECTED]> starnix inc. tollfree: 1-87-pro-linuxthornhill, ontario, canada http://www.starnix.com professional linux services & products
[GENERAL] Should I upgrade Postgres?
I just installed postgres 6.1.1 on Caldera 1.3 (it came with it). Should I upgrade this immediately or is this good enough for now? If so, which version should I upgrade to 6.3.x or 6.4.x? Thanks, -- matthew rice, starnix inc.