Re: [ADMIN] postgresql 7.4.2 binary for Red Hat Enterprise Linux 2.1
Christopher Smith <[EMAIL PROTECTED]> writes: > Are there any binaries for the Red Hat Enterprise Linux 2.1. The OS shipped with > Postgresql 7.1.3... I would like to upgrade. Are there any suggestions? Get a more recent SRPM and do "rpmbuild --rebuild". I haven't tried it but I know of no reason it wouldn't work. regards, tom lane ---(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
[ADMIN] Perl stored procedures
Im looking for some documentation on writing stored procedures using PL/Perl. The PostrgeSQL tutorials give only a brief introduction to this which is good but enough : http://www.postgresql.org/docs/7.4/static/plperl.html Can anyone pls send any links to more documentation. Thanks __ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover ---(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
[ADMIN] postgresql 7.4.2 binary for Red Hat Enterprise Linux 2.1
Are there any binaries for the Red Hat Enterprise Linux 2.1. The OS shipped with Postgresql 7.1.3... I would like to upgrade. Are there any suggestions? Thanks Do you Yahoo!?Win a $20,000 Career Makeover at Yahoo! HotJobs
[ADMIN] 7.4.2 out of memory
All, After I upgraded postgres from 7.3.4 to 7.4.2, one of my program got following error: DRROR: out of memory DETAIL: Fail on request of size 92. any idea?? does memory management have big difference between 7.3.4 and 7.4.2??? this program using a chunk of share memory and a lot of temp tables. Thanks. Jie Liang ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [ADMIN] parametrized query
Put it into a shell script like
echo "select * from mytable where id = $1;" | psql $DBNAME
That can be executed using the shell function in psql
\! [COMMAND] execute command in shell or start interactive shell
regards,
-Andreas
On Wednesday 28 April 2004 17:46, Ben Kim wrote:
> I tried but couldn't find an answer if this is possible in psql.
>
> Create a file named test.sql
> select * from mytable where id = ? (or use $1, $2...)
> Then in psql do
> \i test.sql 337
>
> to achieve the same effect "select * from mytable where id=337"
>
> as I would in perl
> $sth = $dbh -> prepare ("insert into mytable values (?, ?, ?)")
>
> Is writing a function the only way? Is there another way that can be done
> without writing a function?
>
> Thanks,
> Ben Kim
>
>
> ---(end of broadcast)---
> TIP 6: Have you searched our list archives?
>
>http://archives.postgresql.org
--
---(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
[ADMIN] parametrized query
I tried but couldn't find an answer if this is possible in psql.
Create a file named test.sql
select * from mytable where id = ? (or use $1, $2...)
Then in psql do
\i test.sql 337
to achieve the same effect "select * from mytable where id=337"
as I would in perl
$sth = $dbh -> prepare ("insert into mytable values (?, ?, ?)")
Is writing a function the only way? Is there another way that can be done
without writing a function?
Thanks,
Ben Kim
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [ADMIN] [JDBC] [PERFORM] is a good practice to create an index on the
On Wed, Apr 28, 2004 at 10:13:14 +0200, Edoardo Ceccarelli <[EMAIL PROTECTED]> wrote: > do you mean that, declaring an index serial, I'd never have to deal with > incrementing its primary key? good to know! That isn't what is happening. Serial is a special type. It is int plus a default rule linked to a sequence. No index is created by default for the serial type. Declaring a column as a primary key will however create a unique index on that column. Also note that you should only assume that the serial values are unique. (This assumes that you don't use setval and that you don't roll a sequence over.) Within a single session you can assume the sequence values will be monotonicly increasing. The values that end up in your table can have gaps. Typically this happens when a transaction rolls back after obtaining a new value from a sequence. It can also happen if you grab sequence values in larger blocks (which might be more efficient if a session normally acquires mulitple values from a particular sequence) than the default 1. > anyway in this particular situation I don't need such accurate > behaviour: this table is filled up with a lot of data twice per week and > it's used only to answer queries. > I could drop it whenever I want :) You really don't want to use oids. ---(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: [ADMIN] [JDBC] [PERFORM] is a good practice to create an index on the
do you mean that, declaring an index serial, I'd never have to deal with incrementing its primary key? good to know! anyway in this particular situation I don't need such accurate behaviour: this table is filled up with a lot of data twice per week and it's used only to answer queries. I could drop it whenever I want :) Thanks again, eddy Christopher Kings-Lynne ha scritto: I am going to use them as primary key of the table, so I'll surely need them unique :) Eduoardo, I REALLY suggest you don't use them at all. You should make a primary key like this: CREATE TABLE blah ( id SERIAL PRIMARY KEY, ... ); Also note that by default, OIDs are NOT dumped by pg_dump. You will need to add extra switches to your pg_dump backup to ensure that they are. Chris ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [ADMIN] [JDBC] [PERFORM] is a good practice to create an index on the
do you mean that, declaring an index serial, I'd never have to deal with incrementing its primary key? good to know! Yep. You can use 'DEFAULT' as the value, eg: INSERT INTO blah (DEFAULT, ...); anyway in this particular situation I don't need such accurate behaviour: this table is filled up with a lot of data twice per week and it's used only to answer queries. I could drop it whenever I want :) Sure. Chris ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
