On Fri, Aug 11, 2006 at 04:40:36PM -0600, Michael Fuhr wrote:
> > > EXEC SQL CONNECT TO 'unix:postgresql://sql.mydomain.com/mydb' AS
> > > myconnection USER john;
> > >
> > > Should that be changed? It's wrong on two counts as far as
> >
> > I think so yes.
>
> Will you take care of it or sho
On Sun, Aug 13, 2006 at 01:50:13AM -0400, Harpreet Dhaliwal wrote:
> I'm really not able to connect to my database server.
> ...
Again, your example works nicely for me. This has to be a problem with
your local setup. You should get the same connection problem using psql
on the same machine with t
Tom
thanks for to respond quickly, see more below
> marcelo Cortez <[EMAIL PROTECTED]> writes:
> > Then i've created "normal" tables but the wal
> file
> > generated by this tables grows and grows.
>
> The WAL files shouldn't grow indefinitely unless
> you've got some
> fairly serious proble
On Mon, 2006-08-14 at 15:51 -0400, Tom Lane wrote:
Whose 7.x manual? This stuff has been there since we invented the
"version 1" function call convention, which was 7.3 or before. There
is some documentation in the SGML docs, but really we kind of expect you
to look at the standard built-in
On Monday 14 August 2006 02:46 pm, Adrian Klaver wrote:
> > Let current max id = x
> >
> > Transaction 1 (t1) does a select max(id) for update, gets a lock on the
> > last tuple at the time of the select, and gets x as a value for max id
> >
> > Transaction 2 (t2) does a select max(id) for update,
Brad Nicholson wrote:
On Mon, 2006-08-14 at 16:08 -0400, Berend Tober wrote:
Jorge Godoy wrote:
Chris <[EMAIL PROTECTED]> writes:
I'm not sure what type of lock you'd need to make sure no other transactions
updated the table (see
http://www.postgresql.org/docs/8.1/interactive/sql-lock.h
On Monday 14 August 2006 01:59 pm, Brad Nicholson wrote:
> On Mon, 2006-08-14 at 16:08 -0400, Berend Tober wrote:
> > Jorge Godoy wrote:
> > > Chris <[EMAIL PROTECTED]> writes:
> > >>I'm not sure what type of lock you'd need to make sure no other
> > >> transactions updated the table (see
> > >>htt
marcelo Cortez <[EMAIL PROTECTED]> writes:
> Then i've created "normal" tables but the wal file
> generated by this tables grows and grows.
The WAL files shouldn't grow indefinitely unless you've got some
fairly serious problem that is preventing checkpoints from occurring.
Look in the server log
On Mon, Aug 14, 2006 at 05:32:41PM -0300, marcelo Cortez wrote:
> folks
Hi,
> I have a asp application connected with postgres. The postgres
> temporary tables is useless because i need remain this tables between
> sessions, perfomance reasons. This tables are created on the fly and
> remain be
Jeff Davis wrote:
> I have noticed that all SELECT queries alone in a transaction also
> update pg_stat_database (I know it's just a view that calls
> pg_stat_get_db_xact_commit()).
The stuff in the stats collector is not stored on disk. Or, rather, it
is, but not in the same way as regular table
On Mon, 2006-08-14 at 16:08 -0400, Berend Tober wrote:
> Jorge Godoy wrote:
>
> > Chris <[EMAIL PROTECTED]> writes:
> >
> >
> >>I'm not sure what type of lock you'd need to make sure no other transactions
> >>updated the table (see
> >>http://www.postgresql.org/docs/8.1/interactive/sql-lock.html
folks
I have a asp application connected with postgres.
The postgres temporary tables is useless because i
need remain this tables between sessions, perfomance
reasons.
This tables are created on the fly and remain between
session but asp server finalize connection and
temporary table are droppe
Harald Fuchs <[EMAIL PROTECTED]> writes:
> In article <[EMAIL PROTECTED]>,
> Jorge Godoy <[EMAIL PROTECTED]> writes:
>
>> Harald Fuchs <[EMAIL PROTECTED]> writes:
>>> Why putting gapless numbers into the database at all? Just calculate them
>>> at
>>> query time.
>
>> And how would you retrieve
In article <[EMAIL PROTECTED]>,
Scott Ribe <[EMAIL PROTECTED]> writes:
>> Why putting gapless numbers into the database at all? Just
>> calculate them at query time.
> There is ABSOLUTELY NO WAY that would be acceptable for accounting or legal
> purposes. It would be the same as fabricating the
In article <[EMAIL PROTECTED]>,
Jorge Godoy <[EMAIL PROTECTED]> writes:
> Harald Fuchs <[EMAIL PROTECTED]> writes:
>> Why putting gapless numbers into the database at all? Just calculate them at
>> query time.
> And how would you retrieve the record that corresponds to invoice number
> #16355, f
In article <[EMAIL PROTECTED]>,
Richard Broersma Jr <[EMAIL PROTECTED]> writes:
> I am curious, can you calculate something like this using only sql? Or you
> you need to employee a
> procedural language like plpsgql?
You could use something like
SELECT (SELECT count(*) FROM tbl t2 WHERE t2.i
Jorge Godoy wrote:
Chris <[EMAIL PROTECTED]> writes:
I'm not sure what type of lock you'd need to make sure no other transactions
updated the table (see
http://www.postgresql.org/docs/8.1/interactive/sql-lock.html) but "in theory"
something like this should work:
begin;
select id from table
Reece Hart <[EMAIL PROTECTED]> writes:
> On Mon, 2006-08-14 at 11:27 -0400, Tom Lane wrote:
>> The usual way to get a C string from a TEXT datum is to call textout,
>> eg
>> str = DatumGetCString(DirectFunctionCall1(textout, datumval));
> Yikes! I've been accessing VARDATA text data like Michael
I have noticed that all SELECT queries alone in a transaction also
update pg_stat_database (I know it's just a view that calls
pg_stat_get_db_xact_commit()).
Does that mean that SELECTs by themselves require a disk write? If so,
is that a synchronous disk write? Is it due to something else entirel
> Why putting gapless numbers into the database at all? Just calculate them at
> query time.
There is ABSOLUTELY NO WAY that would be acceptable for accounting or legal
purposes. It would be the same as fabricating the numbers during an audit.
--
Scott Ribe
[EMAIL PROTECTED]
http://www.killerby
Michael Enke recently asked in pgsql-bugs about VARDATA and C strings
(BUG #2574: C function: arg TEXT data corrupt). Since that's not a bug,
I've moved this follow-up to pgsql-general.
On Mon, 2006-08-14 at 11:27 -0400, Tom Lane wrote:
> The usual way to get a C string from a TEXT datum is to c
On 8/14/06, Lee A Reum <[EMAIL PROTECTED]> wrote:
Hi,
I need your help!
I vacuumed an entire database because it was having a transaction wraparound
problem.
Then I dropped the database.
After running ANALYZE, the entry of the database is gone as I expected.
But when I try to connect to other
Harald Fuchs <[EMAIL PROTECTED]> writes:
> Why putting gapless numbers into the database at all? Just calculate them at
> query time.
And how would you retrieve the record that corresponds to invoice number
#16355, for example? Recalculating few records is fine, but millions of them
everytime y
> > AgentM <[EMAIL PROTECTED]> writes:
> >> Since the gapless numbers are purely for the benefit of the tax people, you
> >> could build your db with regular sequences as primary keys and then
> >> regularly
> >> (or just before tax-time) insert into a table which maps the gapless
> >> sequence
In article <[EMAIL PROTECTED]>,
Jorge Godoy <[EMAIL PROTECTED]> writes:
> AgentM <[EMAIL PROTECTED]> writes:
>> Since the gapless numbers are purely for the benefit of the tax people, you
>> could build your db with regular sequences as primary keys and then
>> regularly
>> (or just before tax-t
On Sat, 2006-08-12 at 08:08 -0700, RPK wrote:
> How can I migrate a PostgreSQL database to MySQL or MS Access? Are there any
> tools available?
Although migrating away from PostgreSQL is not a popular idea on this
list, it can be done.
If you're using any PostgreSQL-specific features, plan how yo
AgentM <[EMAIL PROTECTED]> writes:
> Since the gapless numbers are purely for the benefit of the tax people, you
> could build your db with regular sequences as primary keys and then regularly
> (or just before tax-time) insert into a table which maps the gapless sequence
> to the real primary k
On Sun, Aug 13, 2006 at 10:48:37AM -0700, Jim Bryan wrote:
> Hi! In a function to insert rows into a table, I keep
> getting ERROR: prepared statement "updateplan" already
> exists. If any ideas; thanks.
As the error says, you already have a prepared statement named
"updateplan". To reuse that
Since the gapless numbers are purely for the benefit of the tax
people, you could build your db with regular sequences as primary
keys and then regularly (or just before tax-time) insert into a table
which maps the gapless sequence to the real primary key.
-M
---(
for an excellent book on keeping things where they should be go buy:
"The ART of SQL" by Stephane Faroult. Sample chapter online.
http://www.oreilly.com/catalog/artofsql/
It's an excellent read, and provides ample arguments for keeping
constraint management with the database and not in each of th
Hi,
I have a database with a lot of schemas; now one schema has been added,
re-integrating a former separate database (of course, there are good reasons to
do so). This "new" schema contains very much data which is rarely changed;
thus, it would be sufficient to save it much less often than the
Hi! In a function to insert rows into a table, I keep
getting ERROR: prepared statement "updateplan" already
exists. If any ideas; thanks.
CREATE OR REPLACE FUNCTION testPreparedStatement()
RETURNS SETOF FLOAT AS $$
DECLARE
tryint1 int4:=1 ;
tryint2 int4:=2 ;
BEGIN
PREPARE updatePlan
Jorge Godoy wrote:
> Chris <[EMAIL PROTECTED]> writes:
>
> > I'm not sure what type of lock you'd need to make sure no other transactions
> > updated the table (see
> > http://www.postgresql.org/docs/8.1/interactive/sql-lock.html) but "in
> > theory"
> > something like this should work:
> >
> > b
Hi,
I need your help!
I vacuumed an entire database because it was having a transaction wraparound problem.
Then I dropped the database.
After running ANALYZE, the entry of the database is gone as I expected.
But when I try to connect to other databases I get the same transaction wraparound err
Michael Fuhr <[EMAIL PROTECTED]> writes:
> Automatically use indexes for MIN() and MAX() (Tom)
>
> In previous releases, the only way to use an index for MIN()
> or MAX() was to rewrite the query as SELECT col FROM tab ORDER
> BY col LIMIT 1. Index usage now happens automatica
On Mon, Aug 14, 2006 at 09:09:51AM -0300, Jorge Godoy wrote:
> Chris <[EMAIL PROTECTED]> writes:
> > P.S. I'm sure in older versions this query wouldn't use an index:
> > select max(id) from table;
>
> It doesn't. You'd have to do what you did: "order by desc limit 1" to
> have it using indexes.
Chris <[EMAIL PROTECTED]> writes:
> I'm not sure what type of lock you'd need to make sure no other transactions
> updated the table (see
> http://www.postgresql.org/docs/8.1/interactive/sql-lock.html) but "in theory"
> something like this should work:
>
> begin;
> select id from table order by id
[EMAIL PROTECTED] wrote:
> How can I migrate a PostgreSQL database to MySQL or MS
> Access? Are there any tools available?
Hi,
Can we know maybe why you want to do this?
---
Philippe Lang
Attik System
smime.p7s
Description: S/MIME cryptographic signature
38 matches
Mail list logo
