[GENERAL] Dump requried for beta1 beta3?
Is a dump and reload required when going from beta1 to beta3? Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[GENERAL] SMgrRelation hashtable corrupted
On 8 beta1 I get 'SMgrRelation hashtable corrupted' *sometimes* when executing the following, but only when there are other clients connecting to the same database. ALTER TABLE declines ALTER COLUMN comp_name TYPE varchar(128), ALTER COLUMN f_name1 TYPE varchar(48), ALTER COLUMN l_name1 TYPE varchar(48), ALTER COLUMN country TYPE varchar(48); Chris ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[GENERAL] radius authentication
Has anyone ever taken a look at adding radius authentication to Postgresql? I know it's not terribly secure in itself, but some 2 factor authentication schemes like Cryptocard use it for verifying one time passwords, and at least in our case having 2 factor authentication for remote access would be really nice. ---(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] Clustering, mirroriing, or replication?
Does anyone know what's the most reliable platform postgresql can run on? With or without scheduled downtime? This reminded me... Not long ago I was looking at used sun servers. You can pick up refurbished sun enterprise systems for between $4,000 and $10,000 fairly easily. For instance an enterprise E3500 with 8 processors, 4gb ram, and 8 18gb fibre channel drives was only $5,000. I couldn't put together an equivalent intel system for the same price. Chris ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [GENERAL] 7.4.3 server panic
(gdb) bt #0 0x284f9dcf in kill () from /lib/libc.so.5 #1 0x284ee878 in raise () from /lib/libc.so.5 #2 0x28566f82 in abort () from /lib/libc.so.5 #3 0x08226a6a in errfinish () #4 0x08226953 in errfinish () #5 0x0822f54d in GetUserNameFromId () #6 0x081183a3 in show_session_authorization () #7 0x08232fe7 in show_all_settings () #8 0x0823196b in AtEOXact_GUC () #9 0x0823164f in AtEOXact_GUC () #10 0x08094cbd in XactPopRollback () #11 0x081a2334 in PostgresMain () The trace is a bit bogus, but it did help me figure out what's going on: I think that we're trying to report the current session authorization to the client (which is something that happens automatically on any change) and it's referencing a deleted user. Is it possible that your setup is deleting the user that the entire session is running as? regards, tom lane By entire session do you mean the superuser that initially makes the connection? If so, then definitely no that user is not deleted. It's possible that a set session authorization was issued, the current session user was then deleted by another connection, and then the session of the deleted user tried to report. I am calling reset session authorization at the start of every run of our application, but I could have missed something so that it does end up in a state of trying to report on a user session where the user no longer exists. Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[GENERAL] 7.4.3 server panic
I have been able to crash the server a few times with the following function
when it is called on a user and schema that was recently deleted. Following
is a log of what happened and also the function that was called. This is
7.4.3 on Freebsd 5.2.1. It doesn't always panic when it encounters a
deleted user/schema, it's kind of sporadic but happens often enough that
it's easy to duplicate.
Chris
--
CREATE OR REPLACE FUNCTION setuser(varchar) RETURNS integer AS
'
DECLARE
in_username ALIAS FOR \$1;
BEGIN
EXECUTE ''SET SESSION AUTHORIZATION '' || in_username;
EXECUTE ''SET SEARCH_PATH TO '' || in_username || '',PUBLIC'';
RETURN 1;
END '
LANGUAGE 'plpgsql';
-
LOG: statement: select * from
setuser('support')
LOG: statement: SET SESSION AUTHORIZATION support
CONTEXT: PL/pgSQL function setuser line 4 at execute statement
LOG: statement: SET SEARCH_PATH TO support,PUBLIC
CONTEXT: PL/pgSQL function setuser line 5 at execute statement
ERROR: schema support does not exist
CONTEXT: PL/pgSQL function setuser line 5 at execute statement
STATEMENT:select * from
setuser('support')
ERROR: invalid user ID: 194
PANIC: error during error recovery, giving up
LOG: server process (PID 38302) was terminated by signal 6
LOG: terminating any other active server processes
WARNING: terminating connection because of crash of another server process
DETAIL: The postmaster has commanded this server process to roll back the
current transaction and exit, because another server process exited
abnormally and possibly corrupted shared memory.
HINT: In a moment you should be able to reconnect to the database and
repeat your command.
---(end of broadcast)---
TIP 8: explain analyze is your friend
[GENERAL] Possible SET SESSION AUTHORIZATION bug
It doesn't currently seem possible to switch between different users using
SET SESSION AUTHORIZATION. If I log in as the superuser and switch to
another user that works, but if I then switch to a second user in succession
I get permission denied when I try to select from a table that the user does
have access to. Following is a cut and paste of two sessions showing what I
mean (with certain details masked out).
defender# psql db1-U pgsql
lcome to psql 7.4, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit
paygw=# set search_path to poi,public;
SET
paygw=# set session authorization poi;
SET
paygw= select * from get_accountsettings_by_username('poi');
settletype | fraudchecks | mer_id | username | cgipass |test_card |
testcard_status | network | dupchecks | gatewaypass | duptime |
itemtypes_allowed | debug_log
+-++--+-+--+
-+-+---+-+---+--
-+---
AUTO | OFF | 9300 | poi | | XX |
vital | OFF | | 1 seconds | 1 | ON
(1 row)
paygw= reset session authorization;
RESET
paygw=# set search_path to jdonline,public;
SET
paygw=# set session authorization jdonline;
SET
paygw= select * from get_accountsettings_by_username('jdonline');
ERROR: permission denied for relation account_settings
CONTEXT: PL/pgSQL function get_accountsettings_by_username line 5 at
select into variables
paygw= \q
-
psql db1 -U jdonline
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit
paygw= set search_path to jdonline,public;
SET
paygw= select * from get_accountsettings_by_username('jdonline');
settletype | fraudchecks | mer_id | username | cgipass |test_card |
testcard_status | network | dupchecks | gatewaypass | duptime |
itemtypes_allowed | debug_log
+-++--+-+--+
-+-+---+-+--+---
+---
AUTO | OFF | 0502 | jdonline | XX| | fhms
| ON| | 3 months | 1 | ON
(1 row)
paygw=
---(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
Re: [GENERAL] Possible SET SESSION AUTHORIZATION bug
A followup on this. If I select * from account_settings directly it
works, but if I call the function get_accountsettings_by_username it
fails. So it seems like an issue with functions in particular. Following
is the function in question if that helps.
CREATE OR REPLACE FUNCTION get_accountsettings_by_username(varchar) RETURNS
acctsettingsrec AS
'
DECLARE
r acctsettingsrec%ROWTYPE;
in_username ALIAS FOR $1;
BEGIN
SELECT INTO r
settletype,fraudchecks,mer_id,username,cgipass,test_card,testcard_status,net
work,dupchecks,gatewaypass,duptime,item
types_allowed,debug_log from account_settings where username = in_username;
RETURN r;
END '
LANGUAGE 'plpgsql';
- Original Message -
From: Chris Ochs [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, June 21, 2004 8:07 AM
Subject: [GENERAL] Possible SET SESSION AUTHORIZATION bug
It doesn't currently seem possible to switch between different users using
SET SESSION AUTHORIZATION. If I log in as the superuser and switch to
another user that works, but if I then switch to a second user in
succession
I get permission denied when I try to select from a table that the user
does
have access to. Following is a cut and paste of two sessions showing what
I
mean (with certain details masked out).
defender# psql db1-U pgsql
lcome to psql 7.4, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit
paygw=# set search_path to poi,public;
SET
paygw=# set session authorization poi;
SET
paygw= select * from get_accountsettings_by_username('poi');
settletype | fraudchecks | mer_id | username | cgipass |test_card
|
testcard_status | network | dupchecks | gatewaypass | duptime |
itemtypes_allowed | debug_log
+-++--+-+-
-+
-+-+---+-+---+
--
-+---
AUTO | OFF | 9300 | poi | | XX |
vital | OFF | | 1 seconds | 1 | ON
(1 row)
paygw= reset session authorization;
RESET
paygw=# set search_path to jdonline,public;
SET
paygw=# set session authorization jdonline;
SET
paygw= select * from get_accountsettings_by_username('jdonline');
ERROR: permission denied for relation account_settings
CONTEXT: PL/pgSQL function get_accountsettings_by_username line 5 at
select into variables
paygw= \q
-
psql db1 -U jdonline
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit
paygw= set search_path to jdonline,public;
SET
paygw= select * from get_accountsettings_by_username('jdonline');
settletype | fraudchecks | mer_id | username | cgipass |test_card
|
testcard_status | network | dupchecks | gatewaypass | duptime |
itemtypes_allowed | debug_log
+-++--+-+-
-+
-+-+---+-+--+-
--
+---
AUTO | OFF | 0502 | jdonline | XX| |
fhms
| ON| | 3 months | 1 | ON
(1 row)
paygw=
---(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
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] Possible SET SESSION AUTHORIZATION bug
Ok this probably isn't a bug but a side affect of how functions are cached.
Changing the function to use EXECUTE to perform the query works. I don't
know if this particular scenario was ever even though of before, or if in
the future it would make sense to have the query planner not cache the
session user/current user? I'll leave that to those that understand the
implications more than I do.
Chris
- Original Message -
From: Chris Ochs [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, June 21, 2004 8:25 AM
Subject: Re: [GENERAL] Possible SET SESSION AUTHORIZATION bug
A followup on this. If I select * from account_settings directly it
works, but if I call the function get_accountsettings_by_username it
fails. So it seems like an issue with functions in particular. Following
is the function in question if that helps.
CREATE OR REPLACE FUNCTION get_accountsettings_by_username(varchar)
RETURNS
acctsettingsrec AS
'
DECLARE
r acctsettingsrec%ROWTYPE;
in_username ALIAS FOR $1;
BEGIN
SELECT INTO r
settletype,fraudchecks,mer_id,username,cgipass,test_card,testcard_status,net
work,dupchecks,gatewaypass,duptime,item
types_allowed,debug_log from account_settings where username =
in_username;
RETURN r;
END '
LANGUAGE 'plpgsql';
- Original Message -
From: Chris Ochs [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, June 21, 2004 8:07 AM
Subject: [GENERAL] Possible SET SESSION AUTHORIZATION bug
It doesn't currently seem possible to switch between different users
using
SET SESSION AUTHORIZATION. If I log in as the superuser and switch to
another user that works, but if I then switch to a second user in
succession
I get permission denied when I try to select from a table that the user
does
have access to. Following is a cut and paste of two sessions showing
what
I
mean (with certain details masked out).
defender# psql db1-U pgsql
lcome to psql 7.4, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit
paygw=# set search_path to poi,public;
SET
paygw=# set session authorization poi;
SET
paygw= select * from get_accountsettings_by_username('poi');
settletype | fraudchecks | mer_id | username | cgipass |test_card
|
testcard_status | network | dupchecks | gatewaypass | duptime |
itemtypes_allowed | debug_log
+-++--+-+-
-+
-+-+---+-+---+
--
-+---
AUTO | OFF | 9300 | poi | | XX
|
vital | OFF | | 1 seconds | 1 | ON
(1 row)
paygw= reset session authorization;
RESET
paygw=# set search_path to jdonline,public;
SET
paygw=# set session authorization jdonline;
SET
paygw= select * from get_accountsettings_by_username('jdonline');
ERROR: permission denied for relation account_settings
CONTEXT: PL/pgSQL function get_accountsettings_by_username line 5 at
select into variables
paygw= \q
-
psql db1 -U jdonline
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit
paygw= set search_path to jdonline,public;
SET
paygw= select * from get_accountsettings_by_username('jdonline');
settletype | fraudchecks | mer_id | username | cgipass |test_card
|
testcard_status | network | dupchecks | gatewaypass | duptime |
itemtypes_allowed | debug_log
+-++--+-+-
-+
-+-+---+-+--+-
--
+---
AUTO | OFF | 0502 | jdonline | XX| |
fhms
| ON| | 3 months | 1 | ON
(1 row)
paygw=
---(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
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [GENERAL] Possible SET SESSION AUTHORIZATION bug
On my system I get permission denied when I switch to pgtest2 and select *
from pgtest_func.
Chris
-- create objects --
CREATE USER pgtest1 WITH ENCRYPTED PASSWORD 'pass' NOCREATEDB NOCREATEUSER;
CREATE USER pgtest2 WITH ENCRYPTED PASSWORD 'pass' NOCREATEDB NOCREATEUSER;
CREATE SCHEMA pgtest1 AUTHORIZATION pgtest1;
CREATE SCHEMA pgtest2 AUTHORIZATION pgtest2;
CREATE OR REPLACE FUNCTION pgtest_func() returns integer AS '
DECLARE
in_test varchar;
BEGIN
in_test := test FROM pgtest_table;
RETURN 1;
END
' LANGUAGE 'plpgsql';
SET SESSION AUTHORIZATION pgtest1;
SET SEARCH_PATH TO pgtest1,public;
CREATE TABLE pgtest_table
(
test varchar(24)
);
INSERT INTO pgtest_table(test) values('PGTEST1');
RESET SESSION AUTHORIZATION;
SET SESSION AUTHORIZATION pgtest2;
SET SEARCH_PATH TO pgtest2,public;
CREATE TABLE pgtest_table
(
test varchar(24)
);
INSERT INTO pgtest_table(test) values('PGTEST2');
-- switch to pgtest1 and run pgtest_func --
RESET SESSION AUTHORIZATION;
SET SESSION AUTHORIZATION pgtest1;
SET SEARCH_PATH TO pgtest1,public;
SELECT * from pgtest_func();
-- switch to pgtest2 and run pgtest_func --
RESET SESSION AUTHORIZATION;
SET SESSION AUTHORIZATION pgtest2;
SET SEARCH_PATH TO pgtest2,public;
SELECT * from pgtest_func();
RESET SESSION AUTHORIZATION;
DROP USER pgtest1;
DROP USER pgtest2;
DROP SCHEMA pgtest1 CASCADE;
DROP SCHEMA pgtest2 CASCADE;
DROP FUNCTION pgtest_func();
- Original Message -
From: Tom Lane [EMAIL PROTECTED]
To: Chris Ochs [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Monday, June 21, 2004 9:25 AM
Subject: Re: [GENERAL] Possible SET SESSION AUTHORIZATION bug
Chris Ochs [EMAIL PROTECTED] writes:
Ok this probably isn't a bug but a side affect of how functions are
cached.
Changing the function to use EXECUTE to perform the query works. I
don't
know if this particular scenario was ever even though of before, or if
in
the future it would make sense to have the query planner not cache the
session user/current user?
It doesn't cache that. I'm not sure what's going on here ... could you
provide a self-contained test script?
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
[GENERAL] Feature idea
What if SET SESSION AUTHORIZATION could also accept a password so that non superusers could switch to a different user? How difficult would this be? One nice side benefit to this would be that you could effectively connect as many users with Apache::DBI under mod perl without having an open connection for every user. Chris ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Fw: [GENERAL] Feature idea
You know I didn't even think about that, duh. I was thinking of using it inside a function where the password could be obtained on the database server itself somehow, avoiding the need to pass any passwords from the web application and simplifying a rather complicated permission structure we have where we have anonymous users that need insert rights on a whole bunch of different schema's. Chris - Original Message - From: Bruce Momjian [EMAIL PROTECTED] To: Chris Ochs [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, June 15, 2004 8:02 AM Subject: Re: [GENERAL] Feature idea Chris Ochs wrote: What if SET SESSION AUTHORIZATION could also accept a password so that non superusers could switch to a different user? How difficult would this be? Well, the password would go over the wire unencrypted, causing a security problem. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [GENERAL] Feature idea
As much as I hate to say it, if it would be insecure when not using ssl, this is a feature that people would definitely use insecurely and one day it would be labeled as a 'security hole' in postgresql. Chris - Original Message - From: Bill Moran [EMAIL PROTECTED] To: Bruce Momjian [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, June 15, 2004 8:13 AM Subject: Re: [GENERAL] Feature idea Bruce Momjian [EMAIL PROTECTED] wrote: Chris Ochs wrote: What if SET SESSION AUTHORIZATION could also accept a password so that non superusers could switch to a different user? How difficult would this be? Well, the password would go over the wire unencrypted, causing a security problem. Only if encrypted transport is not enabled. With encrypted transport, it would be as secure as anything else, right? Perhaps, it could only be available if transmission encryption is enabled? Then again, there's a certain amount of only the user can shoot his own foot that has to be accepted ... Just thinking out loud ... -- Bill Moran Potential Technologies http://www.potentialtech.com ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[GENERAL] synchronizing MS access and postgresql tables
We have a number of tables in a CRM that is written in MS access that I need to be able to provide a web interface to. I can export the tables just fine using pgadmin II, but I cant' think of a clean way to import them from postgresql back to access. Synchronizing only needs to happen once a day at the most. I was also thinking of using the MS access forms with access tables that are just odbc links to the postgresql database. Does anyone know off hand if changing the MS access tables from a native table to a linked table would require changes in the forms (not counting having to tweak/change data types) ? Chris --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.669 / Virus Database: 431 - Release Date: 4/28/2004 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: embedded/serverless (Re: [GENERAL] serverless postgresql)
I still have to respectfully disagree. Postgresql is IMO just the wrong software for the job, and given that there are still a number of really important things that postgresql lacks, it should concentrate on those.I am not against it however for technical reasons, because those things can always be overcome. I just wouldn't want postgresql to start branching out in different directions at this point, it makes no sense if the project wants to keep focused and one day become comparable side by side to oracle. IMO that should be it's main goal, and embedded functionality would be a detour that has more chances of doing harm then good. Chris Frankly, I am _mighty glad_ that the developers are focussed on enterprise-level applications. Me too. But I think we can get it for small-scale stuff with no impact on the rest. Just an additional function or 6 to make embedded developer's lives easier. Jon ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] Postgress and MYSQL
A good clean replication system is not available for bsd platforms as far as I can tell, which is the preferred OS of choice for many PG installations. I am playing around with Erserver, but the download has to be updated from cvs or it won't even compile (corrupted file in the distribution). It appears to me at first glance that it is not actively being worked on, although it may indeed work (I haven't had a chance to fully configure/test it yet on freebsd 5). The Erserver I downloaded is free, although I was confused also because I found that same page that said it was $1000. I'm still not sure if the erserver I downloaded is the only version, or if there is a commercial version? Chris - Original Message - From: Matt Davies [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 14, 2004 11:12 AM Subject: Re: [GENERAL] Postgress and MYSQL Quoting Joshua D. Drake [EMAIL PROTECTED]: Replication exists in multiple manners for PostgreSQL. There is Mammoth replicator (our product), ErServer (pgsql.com's product), dbmirror, Rserv, and pgCluster. What I meant was integrated replication. When adding more layers to the database there is yet one more possible mechanism for failure at some point. I don't know about you, but Murphy always bites me in the butt. In addition, I found your product VERY interesting, but it kinda puts me off that it is starting at $1000. PG is free, MySQL is not (for my purposes) and costs ~$500 with everything in one tried and true package. MySQL has what 19 million in the bank? I only point out what the userbase is feeling. I have never been attacked as an idiot when using MySQL - I have always had helpful responses instead of RTFM as I have seen and experienced here (and with qmail). To many people starting the decision making process one looks at the type of support and how the group makes you feel. You don't risk the company or project on potential hostility. This is very true. Perception is the key. Again, I point out, PERCEPTION is the key. This can be done regardless of the cash stash in the bank. Sincerely, Joshua D. Drake ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] sql insert function
Yes it was in my function. I thought the docs said that BEGIN and END had
no effect on transactions though? Plus wouldn't there have to be a
transaction active since I was not using autocommit and the inserts did in
fact commit?
I suspect it is the end statement doing this though, I'll take it out and
see what happens.
- Original Message -
From: Stephan Szabo [EMAIL PROTECTED]
To: Chris Ochs [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, January 13, 2004 8:36 AM
Subject: Re: [GENERAL] sql insert function
On Mon, 12 Jan 2004, Chris Ochs wrote:
LOG: statement: begin
LOG: statement: insert into...
LOG: statement:
insert into taxship(s_oid,order_id,mer_id,tax,shipping) values
('-1000',1000,'',1,1);
END
Where is that END coming from? Did you accidentally put it in your
function?
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
[GENERAL] Pl/Perl speed
I am pretty sure I know this already, but every time you run a Pl/Perl function it is just like running a perl script as far as having to load and compile the code right? My application runs under mod perl so I'm thinking that speed is not something I would gain by putting any of the code into the database server via Pl/Perl. Chris ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] sql insert function
Hmmm since the function already knows the type, the quotes aren't needed. If you use them it just inserts a literal $1 and $3. - Original Message - From: Alex Satrapa [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 12, 2004 4:33 PM Subject: Re: [GENERAL] sql insert function Chris Ochs wrote: Never mind, I forgot to quote the quote's... Heh... and here I was thinking you were trying to build a function ;) And I made the same mistake as you... guess I should proofread instead of copy-pasting ;) Alex Satrapa ---(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 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] sql insert function
I am seeing another strange thing when using a function that does an insert instead of doing the insert directly. This is using cached connections with apache/mod_perl. My program starts a transaction, does about 20 inserts, then commits. When I replace once of the inserts with a function that does the insert, when I do the commit I get this message: WARNING: there is no transaction in progress The inserts all commit fine. Do functions used through DBD::Pg do something like turn on autocommit after a function is called? ---(end of broadcast)--- TIP 8: explain analyze is your friend
[GENERAL] problems with transaction blocks
I want to do a series of inserts within a single transaction block, but with postgresql if one insert fails, the whole block is aborted. Is there any way to get around this behavior so that postgresql won't abort the entire transaction if a single insert returns an error? Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
