Nice to see some poker being discussed on this list. Much more
reputable than Stock Trading.
I was once on the LuckyBum side of this in a Casino Limit game.
Opponent: AT
Stuart the LuckyBum: 88
Flop: ATT
Myself and opponent checked that flop, I bet the turn 8 and was
raised, the river 8 saw
the
ot;!" and do it in base 64
instead. There's probably plenty of standard tools and convertors to do
things in base 64.
Best regards,
Stuart Cooper.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
about Command Prompt:
http://www.commandprompt.com/about/
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
> PostgreSQL.Org is having a one day technical conference in Portland,
> Oregon on October 20th 2007. The conference will be held at Portland
> State University, and like PDXPGDay during OSCON there will be a dinner
> and party afterward.
This is wrongly advertised (and dead-linked) on the homepag
PL/Perl won't let you use modules, you need to createlang plperlu
(u for "untrusted") and use that.
Hope this helps,
Stuart.
On 7/16/07, Bruno Lavoie <[EMAIL PROTECTED]> wrote:
hello,
simple problem, I hope I can do this working on! If i'm on a wrong
place, just tell me where I can find answer
No, you can't. The reason there is no "nonvolatile" list of timezones
is that timezones are subject to the whims of politicians, who can and
do change them at the drop of a hat. Read the historical comments in
the zic source files sometime...
It used to be that "fully one third of timezones in
I know that a few versions back PostgreSQL's DBD driver didn't support prepared
statements (the operation was still there, it just wasn't doing the
whole magic),
I imagine that it does today but will investigate further.
There's a very extensive writeup in the documentation of DBD::Pg,
perldoc D
The pg_prepared_statments view will give you information on prepared statments
currently resident in the database backend. I suggest you run your progam
(with a couple of "Enter to continue" breakpoints in the code) and, in another
session, select from pg_prepared_statements and see if the prepare
Is there an advantage to using something like $dbh->prepare($sql) if
the SQL is going to be run once within the scope of the code? The
code block may be run many times in a minute as in a function call ---
while (<>) {
insert_something($_);
}
Will the prepare statement be cached @ the d
"*Really* big sites don't ever have referential integrity. Or if the few
spots they do (like with financial transactions) it's implemented on the
application level (via, say, optimistic locking), never the database level."
Some large sites don't even use data types!
http://www.thestar.com/News/
I have installed postgresql 8.2 on redhat enterprise release WS 4. I
need to use the cube operator which I guess resides in the contrib
modules. Please may I know the link to install the appropricate contrib
module for my linux machine.
1) If you have an automatic updater like yum configured, yo
The Postgres docs are great. Unfortunatelty, at 1600 pages, my printer is a
little weary. Are bound & printed editions available? If not, has anyone
had any good experience printing them via any of the online services? (The
ones I contacted said it was too big for them to print...)
You're rig
Can anybody tell me how to enable autocomplete and history in psql.
Make sure your platform has the readline libraries installed.
Under an RPM based Linux, try
$ rpm -qa | grep readline
You can also under Linux try $ ldd psql
and see if it finds readline.so as one of its dependencies.
I can't
I just came up with a far more problematic case too and wonder if
documentation is enough. Maybe we should warn about potential problems
more loudly.
Imagine the following case: insert into test_table (test) values
(random()) where an insert rule propagates the changes faithfully to the
next
My request at this point is to officially and clearly document this as a
substantial limitation of rules. It is not obvious that this is how
rules are supposed to behave in this case, and even assuming that the
current behavior is desired, it would be nice to let us know this :-)
It's documente
I have been using PostgreSQL 8.2.3 under Redhat Enterprise Linux AS 4, but
when I tried to install the postgresql-plperl RPM I got a sequence of
dependency failures, and remedying them got me into an apparently infinite
loop of dependencies on libpq.so versions.
Try grabbing all the PostgreSQL R
I am executing the following queries (id has a unique key):
1) begin;
1) delete from forum where id = 20;
1) insert into forum (id, name) values (20, 'test');
2) delete from forum where id = 20;
1) commit;
If you do these side by side in interactive psql sessions, you'll see that the
process
So what's he meant to do?
Avoiding terms like "UPGRADATION" would be an excellent start.
Stuart.
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Answers in place:
I'm trying to write a plperl function to copy the new row e.g. NEW in
plpgsql into another table. I was looking for a similar effect to the
INSERT INTO blah VALUES (NEW.*)
Syntax that can be used in plpgsql. So fat the best I have come up with
is:
$collist = "";
$val
this may be a very stupid question. I've always used the source rpms for new
versions. However now I'm faced with a ubuntu server and I never used a
non-rpm system.
Since there is no up-to-date postgresql package I grabbed the source for 8.1.8
and compiled/installed it.
So far so good. Now I'm loo
Hi Allan,
TABLEOPTIONS="-P border=5 -P tableattr=width=\"80%\" -P
tableattr=bgcolor=\"#FF\""
produces
...
...
Seems to hang on to the last.
Yes- you've said -P tableattr twice so the second one overrides the first one.
$ psql -H -P tableattr='width="80%" bgcolor="#FF"'
wor
Hi list,
Could someone tell me what libs are packed in the rpm
below ?
postgresql-libs-8.2.3-1PGDG.i686.rpm
We are concerned about the problem of compatibility with
Oracle and we prefer to check all the libs to not put the
Oracle system down.
I think it is just a metter of rpm -qa
postgre
I have an enormous sql script with an incorrect insert line somewhere.
I can echo the commands to stdout as they are executed, but apparently
errors go to stderr. How can I determine where the problem is?
from memory, if you invoke it from the shell with psql [connection
options] -f filename.sql
23 matches
Mail list logo
