>Actually, I like the 'grid' layout that the functions are listed in -- it
>gives the syntax, the return value and an example of usage, all in a
>single glance.
I do too, the only thing I could think to add would be an example of a
return value, i.e. trunc(42.4) | 42
Rob Nelson
[EMAIL PROTECTE
> I actually do understand the differences among -i (install) -U (upgrade)
>and -F (freshen). What I don't understand is why what _should_ work _isn't_
>working.
>
> For example, as Lamar and others suggested:
>
>[root@salmo rshepard]# rpm -qa | grep postgres
>postgresql-server-6.5.3-1
>postgres
>> Anyway, I crashed my system the other day when I did a "select *" from
>> one
>> of my large tables (about 5.5gb in size).
>
> Well It takes abit more than that to actually crash the system. Can
>you give more details? What _exactly_ happened? Did it hang? Kernel
>panicked? So
>In general I am pretty pissed at RH attitude to system
>upgrade, if I were working in a Production environment,
>I would either hire them and not try anything myself,
>which kinda contradicts the whole Linux philosophy.
Can this kind of stuff get put on a Red Hat mailing list, rather than sent
> Hmm so, if the local administrator wants to compile the source, it
>should go in /usr/local. If he wants to use a package manager, it should go
>somewhere else? Seems either pedantic or silly to me.
Perhaps, but such is how the FHS came out. FWIW, SCO (what I work on daily)
seems to res
> The last thing that a system admin needs when upgrading PostgreSQL is "Oh,
>crap, I forgot to uninstall the RPM of the old one first."
If you're switching from RPM to compiling source, that's your own damn
fault. If you're upgrading (rpm -U) then that isn't a concern, as it does it
for you.
>For prohjects such as this that have commercial documentation, why don't
>they have "patches" for printed books also?
...
>It would be an interesting documentation project that would really keep
>information organized and relatively accessible ('cause sometimes digging
>through webpages and email
>AFAIK you must recompile your PHP if you upgrade your PostgreSQL from 6.x
>to 7.x. While you're at it, you may want to upgrade your PHP as well,
>unless you're already on 4.0.1pl2. :)
We have used the same PHP module before and after upgrading from Postgres
6.5.3 to 7.0.2, under Red Hat 6.2. We
>product (eg. Excel/MSQuery), how have you set up the DSN, did you reboot 17
>times after the install).
Oh, that must be it! I only rebooted 16 times! ;)
Rob Nelson
[EMAIL PROTECTED]
>no they can't ... they can add to the current license, but they can't
>remove it ...
Okay, well that is what's wanted, correct? Or am I reading the mail wrong?
Rob Nelson
[EMAIL PROTECTED]
>I'll ask, but I think he'll say that the license applies to the source; if
>a commercial fork was made, then they are free to hide the source. But if
>they ever release the source, then it has to go under the BSD again.
What I was asking was, if someone forks the code base, aren't they allowed
>not being from maryland but, i would think that the constitution's
>prohibition against ex post facto laws would prevent retro-active
>applications of laws, if the usa actually followed the constitution;
>but that's another topic...
Ex post facto seems pretty one way. If you drop a cigg butt on
12 matches
Mail list logo
