Re: [GENERAL] sql insert function
My function does not call commit, and I have autocommit turned off. In the postgresql server logs it looks like this without using the function: LOG: statement: begin LOG: statement: insert into... LOG: statement: insert into... LOG: statement: insert into... LOG:: statement: commit LOG: statement: begin With the function it does this: 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 CONTEXT: SQL function "taxship" during startup LOG: statement: insert into... LOG:: statement: commit WARNING: there is no transaction in progress LOG: statement: begin In both cases all the data gets inserted correctly, but I would like to know how I could be getting the warning that there is no open transaction. I am running with autocommit turned off, so it seems there would have to be a transaction or the data wouldn't get inserted. Either that or there is something else that is causing the data to commit without an explicit commit being called? I'm at a loss. > Chris Ochs wrote: > > 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? > > Is your function calling 'commit' itself? If so, it could be committing > before your SQL statement issues the 'commit', thus attempting to commit > a transaction which doesn't exist any more. > > DBD::Pg defaults to "AutoCommit" behaviour, unless you explicitly turn > it off: > > my $dbh = DBI->connect ( >"DBI:Pg:dbname=database", "user" , "password", >{AutoCommit => 0} > ); > > HTH > Alex Satrapa > > > ---(end of broadcast)--- > TIP 5: Have you checked our extensive FAQ? > >http://www.postgresql.org/docs/faqs/FAQ.html > ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] Drawbacks of using BYTEA for PK?
"D. Dante Lorenso" <[EMAIL PROTECTED]> writes: > Maybe a better example of my problem is with records throughout the system > like invoices, customer data, etc... If any of these items use a sequence > and that sequence is global to the table in the database and the number is > exposed externally, then it is possible to infer the success of the company > underneath, is it not? Except that's exactly the way business has always been done. Though people usually start new accounts with check# 5 or something like that for precisely that reason. But it's still pretty transparent, and they don't really worry about it too much. What you're saying is fundamentally valid, but I tend to think these kinds of concerns are just generically overblown. My only comment was that just taking an MD5 of the sequence gives you no security. At the very least you have to include a secret. Even then I suspect there are further subtle cryptographic issues. There always are. -- greg ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] Column qualifier issue
"Jim Wilson" <[EMAIL PROTECTED]> writes: > Yes, I think you are correct on that. I was misreading column reference for > column name. Would it be difficult to patch my local copy to either permit > this or strip off the characters from the qualifier portion in the parser? [shrug...] You could probably hack the grammar to throw away a qualifier there, but wouldn't it be easier to fix your incorrect SQL? AFAICS, SQL92 does not allow a qualified name there, and SQL99 does but appears to assign it some completely other semantics than what you're expecting --- looks like an object method call of some kind... so you are in for trouble in the long run if you don't fix your code. 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
Re: [GENERAL] Vacuum Error
Kragen Sitaker <[EMAIL PROTECTED]> writes: > On Mon, Jan 12, 2004 at 06:20:23PM -0500, Tom Lane wrote: >> No; an OID collision would have occurred when you tried to create a >> table. If two tables are present in pg_class then they have different >> OIDs, and shouldn't have any conflicts in pg_statistic. > How would that OID collision manifest? Do you think the error message > might look similar? Similar, but referring to pg_class_oid_index. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [GENERAL] sql insert function
Chris Ochs wrote: 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? Is your function calling 'commit' itself? If so, it could be committing before your SQL statement issues the 'commit', thus attempting to commit a transaction which doesn't exist any more. DBD::Pg defaults to "AutoCommit" behaviour, unless you explicitly turn it off: my $dbh = DBI->connect ( "DBI:Pg:dbname=database", "user" , "password", {AutoCommit => 0} ); HTH Alex Satrapa ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [GENERAL] Drawbacks of using BYTEA for PK?
they can try to look up information on other customers by doing: http://domain.com/application/load_record.html?customer_id=12346 http://domain.com/application/load_record.html?customer_id=12344 ...basically walking the sequence. Sure, you will protect against this to happen. NOW, if you use a GUID: Security != obscurity. While using GUIDs may make it harder to get hacked, it in no way actually increases security. Real security comes from secure code, period. Well, uh, you're both wrong. On the one hand if your GUIDs are just an MD5 of a sequence then they're just as guessable as the sequence. Its not a question of right or wrong. Its the method. One thing I see here is a failing to use several security methods at different layerswhy are you not using HTTPS (i.e. authentication)? What about using a crytographic cookies to identify your session and link that to you userid (after authorization)? Ok, my point is not one of security as much as the obscurity. I have the security aspect already covered whereby I only select the customer record from the database where the logged in account has access to the record. So, if you are not the admin or the actual customer, the select will return a code indicating that you do not have permission to view the given record. Maybe a better example of my problem is with records throughout the system like invoices, customer data, etc... If any of these items use a sequence and that sequence is global to the table in the database and the number is exposed externally, then it is possible to infer the success of the company underneath, is it not? For instance, if I generate sequential numbers for invoice ids and the customer sees #123 as an invoice number one month and sees #128 the next month, it might imply that there are only 4 customers getting invoiced each month. Another example ... let's say customers can create 'Widgets' in their account. There might be a page that lists all their 'widgets'. If you click on the widget, you can edit it. A link to do this might look as follows: http://.../account/widget_list.html http://.../account/widget_edit.html?widget_id=12345 Well, if the widget_id is a sequence (global to the widget table), then by creating one widget, customer would get widget id (WIDG_1) and another widget (WIDG_2), the customer could see that the widget_id increased by only an amount of N = WIDG_2 - WIDG_1 and would therefore provide the assumption that the number of customers creating widgets in total does not exceed N. I don't see this as much of a problem about 'security' in the respect of who can access the data as much as who can make conclusions about the company beind the data. See what I mean? What do you propose as the best solution for this? Not expose the sequences to the user and use user-enumerated ids? Then a trigger on the table would assign ids like: SELECT (MAX(widget_id)+1) INTO NEW.widget_id WHERE cust_id = NEW.cust_id; But I think after several hundred customer records, this trigger would start getting slow. I don't know really, any ideas? Dante ---(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] Parse error help needed...
Now my function is created ... Thanks guys .. Now getting error while trying to execute it postgres=# select loadme(); WARNING: Error occurred while executing PL/pgSQL function loadme WARNING: line 7 at SQL statement ERROR: SPI_prepare() failed on "commit" Thx again Deep PS: here is fn definition create function loadme() returns text as ' Declare s_out text ; Begin For i in 1..1 loop insert into test values (i,''Test''); end loop; commit; returns s_out; End; ' language 'plpgsql'; -Original Message- From: Larry Rosenman [mailto:[EMAIL PROTECTED] Sent: Monday, January 12, 2004 5:29 PM To: Thapliyal, Deepak; 'PostgreSQL General' Subject: Re: [GENERAL] Parse error help needed... --On Monday, January 12, 2004 17:24:14 -0800 "Thapliyal, Deepak" <[EMAIL PROTECTED]> wrote: > Made the change and used returns in both places now .. Gives me error > > postgres=# \i a.sql > psql:a.sql:10: ERROR: language "plpgsql" does not exist > createlang plpgsql > Any help is appreciated > > Thx > Deep > > create function loadme() returns text as ' > Declare >s_out text ; > Begin > For i in 1..1 loop > insert into test values (i,''Test''); > end loop; > returns s_out; > End; > ' language 'plpgsql'; > > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Alex Satrapa > Sent: Monday, January 12, 2004 4:57 PM > To: PostgreSQL General > Subject: Re: [GENERAL] Parse error help needed... > > > Thapliyal, Deepak wrote: >> create function loadme() return text as ' > > try "RETURNS" instead of "RETURN" > > [the guys writing the function parser might want to consider reporting > what the parser was expecting at this point] > >> Declare >>s_out text ; >> Begin >> For i in 1..1 loop >> insert into test values (i,''Test''); >> end loop; >> return s_out; >> End; >> ' language 'plpgsql'; > > The rest looks fine (works for me - yes I tested it this time) > > 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 6: Have you searched our list archives? > >http://archives.postgresql.org > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] Column qualifier issue
Tom Lane <[EMAIL PROTECTED]> said: > "Jim Wilson" <[EMAIL PROTECTED]> writes: > > As far as I can tell, there isn't a way to get postgresql to accept column > > qualifiers (e.g. tablenames). A 'parse error at or near "."' gets returned. > > You're either very confused or using a *very* old version of Postgres. > > What version is it, what query are you issuing exactly, and what exactly > is the error message? (Cut-and-paste from a psql session would be the > best way to answer the last two ... or if the query is being issued from > another application, you could turn on query logging and send in an > excerpt from the postmaster log.) > > regards, tom lane > This is version 7.2.3, and the same error was produced on 7.4.x (using the phpadmin demo site). Looking at the logs I don't see anything that is addressing this. This syntax isn't required by sql92, but it is allowed (at least that is my reading). Following is a log from a psql session that demonstrates the problem. Best, Jim Wilson bash$ ./bin/psql testdb Welcome to psql, 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 testdb=# select * from test; cola |colb --+ 1 | Record One 2 | 2nd Record (2 rows) kelcodb=# \d test Table "test" Column | Type | Modifiers +---+--- cola | bigint| not null colb | character varying(10) | not null testdb=# update test set test.colb = '2nd Record' where test.cola = 2; ERROR: parser: parse error at or near "." testdb=# update test set colb = '2nd Record' where cola = 2; UPDATE 1 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [GENERAL] Column qualifier issue
Stephan Szabo <[EMAIL PROTECTED]> said: > On Mon, 12 Jan 2004, Tom Lane wrote: > > > "Jim Wilson" <[EMAIL PROTECTED]> writes: > > > As far as I can tell, there isn't a way to get postgresql to accept column > > > qualifiers (e.g. tablenames). A 'parse error at or near "."' gets returned. > > > > You're either very confused or using a *very* old version of Postgres. > > > > What version is it, what query are you issuing exactly, and what exactly > > is the error message? (Cut-and-paste from a psql session would be the > > best way to answer the last two ... or if the query is being issued from > > another application, you could turn on query logging and send in an > > excerpt from the postmaster log.) > > My guess from the rest of his message is something like: > > sszabo=# insert into a (a.x) values ('3'); > ERROR: syntax error at or near "." at character 17 > > (from my 7.5 machine). > > However, AFAICS in sql92 the above isn't valid, because a.x doesn't meet > the syntactic requirements for elements in the column name list. Yes, I think you are correct on that. I was misreading column reference for column name. Would it be difficult to patch my local copy to either permit this or strip off the characters from the qualifier portion in the parser? Best, Jim ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] Parse error help needed...
--On Monday, January 12, 2004 17:24:14 -0800 "Thapliyal, Deepak" <[EMAIL PROTECTED]> wrote: Made the change and used returns in both places now .. Gives me error postgres=# \i a.sql psql:a.sql:10: ERROR: language "plpgsql" does not exist createlang plpgsql Any help is appreciated Thx Deep create function loadme() returns text as ' Declare s_out text ; Begin For i in 1..1 loop insert into test values (i,''Test''); end loop; returns s_out; End; ' language 'plpgsql'; -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Satrapa Sent: Monday, January 12, 2004 4:57 PM To: PostgreSQL General Subject: Re: [GENERAL] Parse error help needed... Thapliyal, Deepak wrote: create function loadme() return text as ' try "RETURNS" instead of "RETURN" [the guys writing the function parser might want to consider reporting what the parser was expecting at this point] Declare s_out text ; Begin For i in 1..1 loop insert into test values (i,''Test''); end loop; return s_out; End; ' language 'plpgsql'; The rest looks fine (works for me - yes I tested it this time) 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 6: Have you searched our list archives? http://archives.postgresql.org -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [GENERAL] Parse error help needed...
Made the change and used returns in both places now .. Gives me error postgres=# \i a.sql psql:a.sql:10: ERROR: language "plpgsql" does not exist Any help is appreciated Thx Deep create function loadme() returns text as ' Declare s_out text ; Begin For i in 1..1 loop insert into test values (i,''Test''); end loop; returns s_out; End; ' language 'plpgsql'; -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Satrapa Sent: Monday, January 12, 2004 4:57 PM To: PostgreSQL General Subject: Re: [GENERAL] Parse error help needed... Thapliyal, Deepak wrote: > create function loadme() return text as ' try "RETURNS" instead of "RETURN" [the guys writing the function parser might want to consider reporting what the parser was expecting at this point] > Declare >s_out text ; > Begin > For i in 1..1 loop > insert into test values (i,''Test''); > end loop; > return s_out; > End; > ' language 'plpgsql'; The rest looks fine (works for me - yes I tested it this time) 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 6: Have you searched our list archives? http://archives.postgresql.org
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
Re: [GENERAL] Parse error help needed...
Thapliyal, Deepak wrote: create function loadme() return text as ' try "RETURNS" instead of "RETURN" [the guys writing the function parser might want to consider reporting what the parser was expecting at this point] Declare s_out text ; Begin For i in 1..1 loop insert into test values (i,''Test''); end loop; return s_out; End; ' language 'plpgsql'; The rest looks fine (works for me - yes I tested it this time) 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
Re: [GENERAL] Parse error help needed...
Thx to doug ... Old error is gone .. But I am now getting new error postgres=# \i a.sql psql:a.sql:10: ERROR: language "plpgsql" does not exist But I verified that I setup plpgsql [EMAIL PROTECTED] createlang -d test -l Procedural languages Name | Trusted? -+-- plpgsql | t (1 row) Can u pls advice if u know whats going on.. Am I missing somin obvious here. .. Thx in advance Deep -Original Message- From: Doug McNaught,,, [mailto:[EMAIL PROTECTED] On Behalf Of Doug McNaught Sent: Monday, January 12, 2004 4:44 PM To: Thapliyal, Deepak Cc: '[EMAIL PROTECTED]' Subject: Re: [GENERAL] Parse error help needed... "Thapliyal, Deepak" <[EMAIL PROTECTED]> writes: > I am getting this error > > postgres=# \i a.sql > psql:a.sql:10: ERROR: parser: parse error at or near "return" at > character 26 > create function loadme() return text as ' ^^ I think you want "returns" here. -Doug ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [GENERAL] Parse error help needed...
"Thapliyal, Deepak" <[EMAIL PROTECTED]> writes: > I am getting this error > > postgres=# \i a.sql > psql:a.sql:10: ERROR: parser: parse error at or near "return" at character > 26 > create function loadme() return text as ' ^^ I think you want "returns" here. -Doug ---(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] 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
[GENERAL] Parse error help needed...
I am getting this error postgres=# \i a.sql psql:a.sql:10: ERROR: parser: parse error at or near "return" at character 26 -- a.sql -- create function loadme() return text as ' Declare s_out text ; Begin For i in 1..1 loop insert into test values (i,''Test''); end loop; return s_out; End; ' language 'plpgsql'; Any help is appreciated Thx Deep PS: I already loaded pl/pgsql in my database [EMAIL PROTECTED] createlang -d test -l Procedural languages Name | Trusted? -+-- plpgsql | t (1 row) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Ochs Sent: Monday, January 12, 2004 4:30 PM To: [EMAIL PROTECTED] Subject: Re: [GENERAL] sql insert function Never mind, I forgot to quote the quote's... Chris > The documentation doesn't have any examples of using an sql language > function to do an insert, andI am at loss as to I am doing wrong here. > The error I get trying to create the function is: ERROR: syntax > error at or near "$1" at character 148 > > CREATE FUNCTION taxship(varchar,integer,varchar,float,float) returns integer > AS ' > insert into taxship(s_oid,order_id,mer_id,tax,shipping) values > ('$1',$2,'$3',$4,$5); SELECT 1; > ' LANGUAGE SQL; > > > ---(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 ---(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] sql insert function
On Mon, 12 Jan 2004 16:21:17 -0800 Chris Ochs <[EMAIL PROTECTED]> wrote: > The documentation doesn't have any examples of using an sql language > function to do an insert, andI am at loss as to I am doing wrong here. > The error I get trying to create the function is: ERROR: syntax error at > or near "$1" at character 148 > CREATE FUNCTION taxship(varchar,integer,varchar,float,float) returns integer > AS ' > insert into taxship(s_oid,order_id,mer_id,tax,shipping) values > ('$1',$2,'$3',$4,$5); > SELECT 1; > ' LANGUAGE SQL; i do believe you need to double up the single quotes inside the function body, e.g. (''$1'',$2,''$3'',$4,$5); otherwise, the quote before the $1 ends up terminating the function body. richard -- Richard Welty [EMAIL PROTECTED] Averill Park Networking 518-573-7592 Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [GENERAL] sql insert function
"Chris Ochs" <[EMAIL PROTECTED]> writes: > The documentation doesn't have any examples of using an sql language > function to do an insert, andI am at loss as to I am doing wrong here. > The error I get trying to create the function is: ERROR: syntax error at > or near "$1" at character 148 > > CREATE FUNCTION taxship(varchar,integer,varchar,float,float) returns integer > AS ' > insert into taxship(s_oid,order_id,mer_id,tax,shipping) values > ('$1',$2,'$3',$4,$5); > SELECT 1; > ' LANGUAGE SQL; When you want to use single quotes inside a quoted string (which is what a function body is) you need to escape them. -Doug ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
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
Re: [GENERAL] sql insert function
Chris Ochs wrote: CREATE FUNCTION taxship(varchar,integer,varchar,float,float) returns integer AS ' insert into taxship(s_oid,order_id,mer_id,tax,shipping) values ('$1',$2,'$3',$4,$5); SELECT 1; ' LANGUAGE SQL; try CREATE FUNCTION taxship (varchar,integer,varchar,float,float) RETURNS integer AS ' BEGIN insert into taxship(s_oid,order_id,mer_id,tax,shipping) values ('$1',$2,'$3',$4,$5); return 1; END' LANGUAGE 'plpgsql'; since what you are trying to do is a compound statement. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[GENERAL] Dump/Restore ordering problem?
First I created a function that selected the next available pin code from a table of pre-defined pin codes: CREATE FUNCTION "public"."get_next_pin_code" () RETURNS varchar AS' DECLARE my_pin_code VARCHAR; BEGIN ... /* this is the pincode we just fetched */ RETURN (my_pin_code); END; 'LANGUAGE 'plpgsql'; Then I created a table that used that function to set a default value: CREATE TABLE "public"."account" ( "acct_id" BIGSERIAL, ..., "acct_pin_code" VARCHAR(16) NOT NULL DEFAULT get_next_pin_code() ) WITH OIDS; But, now when I pg_dump and pg_restore this database to another server, there seems to be a problem with the ordering of the dump in that the account table is not recreated because the function get_next_pin_code() is not yet defined. It seems like the function is not being created until AFTER the table is created and this causes an ordering problem. To dump and restore I've been doing this: pg_dump -U dbuser -Ft dbname | pg_restore -c -Ft | psql -U dbuser -h db.otherdbhost.com dbname I've been able to work around this by creating a TRIGGER that sets the default value instead of defining it in the table definition, but that just seems like a hack. Is there something I need to do to make the dependency ordering work smarter during a dump/restore? Or is this the right way to do it? Dante ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] Case sensitivity
On Mon, 12 Jan 2004, Richard Huxton wrote: > On Sunday 11 January 2004 09:29, Dario Ottaviano wrote: > > I use postgres on a window server (IIS 5.1) > > Is there anybody that knows if is possible to make postgres no case > > sensitive in the manipulating data into tables/views? > > There's no general "case_sensitive = yes/no" flag. There are case-insensitive > operators you can use though. Is there a case insensitive locale? Or is that even possible? ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] History-based (or logged) database.
Yes, I did. For just the simple updating, (not the logging you are doing) NEW is what you want. But OLD is proper for archiving/logging. --elein On Mon, Jan 12, 2004 at 08:22:27PM +0700, Chris Travers wrote: > Hi Elein; > > Nope, OLD is correct. I track the OLD values and then use the view to > combine those with the current ones. This allows the OLAP portions of the > code to hit against *all* the data, while archiving old, outdated > information in the archive table. It also allows deleted tuples to be > tracked with the same trigger since a deleted row doesn't exactly have a NEW > tuple :-) Maybe you misunderstand what I am trying to do? > > Best WIshes, > Chris Travers ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] Drawbacks of using BYTEA for PK?
Tom Lane wrote: Adding an MD5 hash contributes *absolutely zero*, except waste of space, to any attempt to make a GUID. The hash will add no uniqueness that was not there before. The cool thing about a 'GUID' (or in my example a hashed sequence number [sure toss in some entropy if you want it]) is that if you happen to reference that value as a primary key on a table, the URL that passes the argument can not be guessed at easily. For example using a sequence: http://domain.com/application/load_record.html?customer_id=12345 Then, users of the web will assume that you have at most 12345 customers. And they can try to look up information on other customers by doing: http://domain.com/application/load_record.html?customer_id=12346 http://domain.com/application/load_record.html?customer_id=12344 ...basically walking the sequence. Sure, you will protect against this with access rights, BUT...seeing the sequence is a risk and not something you want to happen. NOW, if you use a GUID: http://domain.com/application/load_record.html?customer_id=f46d6296-5362-2526-42e3-1b8ce9d1 Right, so now try to guess the next value in this sequence. It's a little more protective and obfuscated (an advantage in using GUIDs). Dante ---(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] what we need to use postgresql in the enterprise
--- [EMAIL PROTECTED] wrote: > I write this to tell you why we won't use postgresql > even though we wish we > could at a large company. Don't get me wrong I love > postgresql in many > ways and for many reasons , but fact is fact. If > you need more detail I > can be glad to prove all my points. Our goal is to > make logical systems. > We don't want php,perl, or c++ making all the > procedure calls and having > the host language to be checking for errors and > handleing all the > transactions commits and rollbacks. That is not > very logical in a large > batch system. Also please don't tell me to code the > changes myself. I'm > not at that part of the food chain. That is to low > level for me and I > don't have the time to put that hat on. I build the > applications that use > the database systems. Also please feel free to > correct me in any area I > don't know everything I'm just stating my opinion > here > > 1. Need commit roll back in pl/pgsql much like > Oracle does > 2. Need exception handling in pl/pgsql must like > Oracle does > 3. A>Need sub transactions . B>And if an inner > transactions fails it > should not cause all others to fail. If #2 was > robust enough than #3 B > might not be an issue. #1 & #3 both refer to the same thing, i.e. nested transactions. Alvaro Herrera has been working on this for some time, and recently stated on (I think) the pgsql-hackers list that he intended to have nested transactions ready for the next release of PostgreSQL. On the other hand, Tom Lane recently responded to a question about nested transactions by warning about the complexity of the problems needing to be overcome to make that happen, and expressing doubt about an early solution. So you could say that the status is unclear. A question on the -hackers list would probably get more information. Agreed that Oracle-style exception handling in pl/pgsql would be a good thing. If I understand things correctly, the new error codes scheme in PostgreSQL version 7.4 makes that easier to implement than before. But I am not aware of anyone working on it. *** Note To Developers *** Adding Oracle-style exception handling to pl/pgsql would greatly ease the migration path from Oracle to PostgreSQL, and could easily result in many more instances of Postgres being used for enterprise apps that are now using Oracle. But I'm not up to the task, so I'm flagging it here for anyone else who might want to take a crack at it. > > With those two things I could accomplish pretty much > everything with > postgresql that we're currently doing in Oracle. > > 1. It's a must if you have long running complicated > and time consuming > batch processing. There is no reason why one should > say do all of commit > and rollbacks from the client. Our current batch > system gets fired off by > running some sql scripts that start an entry point > into the batch system. > Once the first stored procedure is called it will > call all the rest. This > encapsulates all logic and processing in the > database where it belongs. > There is no client traffic because once that first > script kicks off there > is no outside process running , just our pl/sql. > Now I'm not a postgresql > expert at all but when I read up on it looks like > this is something you > can't accomplish and I see no word of this being > worked on. > > 2. Without this you can't trust complicated code as > far as I'm concerned. I > need to log some errors and continue processing and > for others log and exit > which I think you can do now in pl/pgsql. Point > being pl/pgsql exception > handling is almost nonexistent at best. > > 3. We use this all the time in pl/sql and we need > to. To write this off as > not need is wrong and will not get postgresql to > where it can be(AT THE > TOP). > > > > > > > * > PRIVILEGED AND CONFIDENTIAL: This communication, > including attachments, is for the exclusive use of > addressee and may contain proprietary, confidential > and/or privileged information. If you are not the > intended recipient, any use, copying, disclosure, > dissemination or distribution is strictly > prohibited. If you are not the intended recipient, > please notify the sender immediately by return > e-mail, delete this communication and destroy all > copies. > * > > > ---(end of > broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] Any way to SELECT a list of table names?
On Sat, 10 Jan 2004, Eric Freeman wrote: Is there any way in Postgres to SELECT a list of table names from inside of a C program using ECPG? Something similar to SELECT current_user that will give you all of the tables in the database you are connected to. Not sure if this is what you're trying to do but... "SELECT tablename FROM pg_tables where tablename not like 'pg_%'" Will get a list of tables in the db you're connected to. ---(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] unsubscribe
_ High-speed usersbe more efficient online with the new MSN Premium Internet Software. http://join.msn.com/?pgmarket=en-us&page=byoa/prem&ST=1 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] Any way to SELECT a list of table names?
On Sat, 10 Jan 2004, Eric Freeman wrote: > Is there any way in Postgres to SELECT a list of table names from inside of > a C program using ECPG? > Something similar to SELECT current_user that will give you all of the > tables in the database you are connected to. If you are running 7.4 and have the information_schema you can use that to find out just about anything. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[GENERAL] unsubscribe
unsubscribe ---(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] Drawbacks of using BYTEA for PK?
Tom Lane wrote: David Garamond <[EMAIL PROTECTED]> writes: Perhaps I can make a GUID by MD5( two random numbers || a timestamp || a unique seed like MD5 of '/sbin/ifconfig' output)... Adding an MD5 hash contributes *absolutely zero*, except waste of space, to any attempt to make a GUID. The hash will add no uniqueness that was not there before. Of course, in the above case, MD5 is used to compress the "uniqueness" (which should be more than 128-bit, comprised of: a) [good] random number; b) timestamp; c) a "node ID" element, either from /sbin/config output which contain MAC address, or from the hash of harddisk content, etc) into a 128-bit space. -- dave ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] int8 version of NUMERIC?
On Sun, Jan 11, 2004 at 21:53:09 +0700, David Garamond <[EMAIL PROTECTED]> wrote: > > My concern is that, the PostgreSQL docs says NUMERIC & DECIMAL is very > slow compared to INT/BIGINT. Should I worry about that? Most likely disk IO not cpu will be your bottleneck and the extra overhead of numeric relative to int or float won't be a big deal. Numeric is stored usingh based 1 (at least in 7.4.x) and hence isn't that horrible performance-wise (as compared to say storing it as an ascii string). ---(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] PostgreeSQL C header files
hi, I have done work on sourceforge for my c++ cgi library. It is at http://sourceforge.net/projects/cgiutils2/ It is built up of 3 separate libraries, the cgi library which parses post requests and gets form values and such, a session library, and a template library which uses a custom parser. The first and last don't need any data storage. For sessions, it doesn't use a postgresql backend, becase it uses mmap and semaphores for memory management of sessions. I am in the process of adding mysql and postgresql c++ library code and configure switches to allow the user to store session information in the databases, however, instead of in unix memory. I have a website which exclusively generates all content from the cgi c++ library (it uses the cgi c++ library to do sessions, templates and form processing) and it is http://www.myowndictionary.com/. That client uses postgresql c++ library off gborg which is libpqxx. Source for the client is http://www.sirfsup.com/languages/cPP/lcgi/decoy.htm Libpqxx has docs of its own but lots of it reproduces what's in libpq docs as it's just a c++ wrapper with classes methods and calls and such for the C code. I am always looking for developers to help with the sourceforge project, if you want you could write the libpqxx class for the sessions or something. On Wed, Dec 24, 2003 at 11:06:21AM +0100, Christian Kienle wrote: > > See the "Client Interfaces" and possibly the "Server Programming" > > sections in the PostgreSQL manual: > > http://www.postgresql.org/docs/current/static/client-interfaces.html > > http://www.postgresql.org/docs/current/static/server-programming.html > > The examples in the contrib directory of the source distribution might > > also be helpful. > > Thank you very much. > > > > > > -- > Linux is like a wigwam - no gates, no windows and an apache inside. > > > ---(end of broadcast)--- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) -- joe speigle ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] Drawbacks of using BYTEA for PK?
David Garamond <[EMAIL PROTECTED]> writes: > Perhaps I can make a GUID by MD5( two random numbers || a timestamp || a > unique seed like MD5 of '/sbin/ifconfig' output)... Adding an MD5 hash contributes *absolutely zero*, except waste of space, to any attempt to make a GUID. The hash will add no uniqueness that was not there before. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] insertion with trigger failed unexpectedly
Richard Huxton <[EMAIL PROTECTED]> writes: > On Monday 12 January 2004 05:57, [EMAIL PROTECTED] wrote: >> i have a problem with insertion data and running post insert trigger >> on it. > Better post the CREATE TABLE, trigger code and a sample INSERT. And the specific error messages you're getting, and the PG version number. Also, you say it happens "twice a day" --- do you mean at specific times of day, like noon and midnight? regards, tom lane ---(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] what we need to use postgresql in the enterprise
I couldn't agree with you more. I'm just a developer in a very large company and getting anyone to listen and then understand that logic would be a nightmare to say the least. If it was my company I would put money toward those issues. Robert Treat <[EMAIL PROTECTED]To: [EMAIL PROTECTED], [EMAIL PROTECTED] eforge.net>cc: Subject: Re: [GENERAL] what we need to use postgresql in the enterprise 01/12/2004 12:45 AM I think your pretty much on target with the below. It is possible to work around these issues on some level, but I can see how that might get unwieldly in a hurry. While I won't tell you to "go code it if you need it", I might ask that you consider what your paying in Oracle licenses and think about spending that money to hire someone to develop those features in PostgreSQL, I'm thinking you'd save money in the long run. Robert Treat On Friday 09 January 2004 14:48, [EMAIL PROTECTED] wrote: > I write this to tell you why we won't use postgresql even though we wish we > could at a large company. Don't get me wrong I love postgresql in many > ways and for many reasons , but fact is fact. If you need more detail I > can be glad to prove all my points. Our goal is to make logical systems. > We don't want php,perl, or c++ making all the procedure calls and having > the host language to be checking for errors and handleing all the > transactions commits and rollbacks. That is not very logical in a large > batch system. Also please don't tell me to code the changes myself. I'm > not at that part of the food chain. That is to low level for me and I > don't have the time to put that hat on. I build the applications that use > the database systems. Also please feel free to correct me in any area I > don't know everything I'm just stating my opinion here > > 1. Need commit roll back in pl/pgsql much like Oracle does > 2. Need exception handling in pl/pgsql must like Oracle does > 3. A>Need sub transactions . B>And if an inner transactions fails it > should not cause all others to fail. If #2 was robust enough than #3 B > might not be an issue. > > With those two things I could accomplish pretty much everything with > postgresql that we're currently doing in Oracle. > > 1. It's a must if you have long running complicated and time consuming > batch processing. There is no reason why one should say do all of commit > and rollbacks from the client. Our current batch system gets fired off by > running some sql scripts that start an entry point into the batch system. > Once the first stored procedure is called it will call all the rest. This > encapsulates all logic and processing in the database where it belongs. > There is no client traffic because once that first script kicks off there > is no outside process running , just our pl/sql. Now I'm not a postgresql > expert at all but when I read up on it looks like this is something you > can't accomplish and I see no word of this being worked on. > > 2. Without this you can't trust complicated code as far as I'm concerned. I > need to log some errors and continue processing and for others log and exit > which I think you can do now in pl/pgsql. Point being pl/pgsql exception > handling is almost nonexistent at best. > > 3. We use this all the time in pl/sql and we need to. To write this off as > not need is wrong and will not get postgresql to where it can be(AT THE > TOP). > > > > > > > * > PRIVILEGED AND CONFIDENTIAL: This communication, including attachments, is > for the exclusive use of addressee and may contain proprietary, > confidential and/or privileged information. If you are not the intended > recipient, any use, copying, disclosure, dissemination or distribution is > strictly prohibited. If you are not the intended recipient, please notify > the sender immediately by return e-mail, delete this communication and > destroy all copies. > ***
Re: [GENERAL] Drawbacks of using BYTEA for PK?
D. Dante Lorenso wrote: GUID? Isn't that really nothing more than an MD5 on a sequence? SELECT (MD5(NEXTVAL('my_table_seq'))) AS my_guid; I know there are several algorithms to generate GUID, but this is certainly inadequate :-) You need to make sure that the generated GUID will be unique throughout cyberspace (or to be more precise, the GUID should have a very very small chance of colliding with other people's GUID). Even OID is not a good seed at all. Perhaps I can make a GUID by MD5( two random numbers || a timestamp || a unique seed like MD5 of '/sbin/ifconfig' output)... Since 7.4 has the md5 function built-in, there's your support ;-) Well, until there's a GUID or INT128 or BIGBIGINT builtin type I doubt many people will regard PostgreSQL as fully supporting GUID. I believe there's the pguuid project in GBorg site that does something like this. -- dave ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] History-based (or logged) database.
Hi Elein; Nope, OLD is correct. I track the OLD values and then use the view to combine those with the current ones. This allows the OLAP portions of the code to hit against *all* the data, while archiving old, outdated information in the archive table. It also allows deleted tuples to be tracked with the same trigger since a deleted row doesn't exactly have a NEW tuple :-) Maybe you misunderstand what I am trying to do? Best WIshes, Chris Travers ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] insertion with trigger failed unexpectedly
Dear Anton Nikiforov, The problem: From the very beginning everything was fine and all records that i was getting from routers were calculated just right. I spent a weeks monitoring and testing my software. Now i have 10.000.000 records in raw table and when i'm inserting data alot of records are missing in raw and daily. Sometimes i got UPDATE failed errors, sometimes INSERT failed, but in general i'm getting this messages twice a day but not only two records are missing - hundreds of them. I am suggesting something but may be its wrong in eithercase we would require your PostgreSQL version number etc Also Checkout the disk space if you have run out of diskspace Currently i have no idea where to go and what to check. I did my tests mainly on FreeBSD platform and now i did tests on RedHat Linux and the result is the same - some records just did not This is a real problem its seems no disk space probelm in this case would you please show us the code reach the database (trigger has logger that is saying that everything Regards, Vishal Kashyap ---(end of broadcast)--- TIP 8: explain analyze is your friend
[GENERAL] Dump tables with pg_dump - no or different Owner
Hi! Have a problem, probably easy to solve... I want to dump a database which resides on my local server with another, and not existing, owner than the one who actually owns it locally. The beginning of the dump file looks like: \connect - postgres SET search_path = public, pg_catalog; -- -- TOC entry 2 (OID 16978) -- Name: ingrediens; Type: TABLE; Schema: public; Owner: postgres I want all instances of "postgres" to be changed in the dump (only) to for example "anotheruser" (which will be the one on the remote server). I'm having problem dumping from the first to the second server, and suspects that the differing owners can be the key to solve the problem... In advance, lots of thanks, sincerely: Victor ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] problems dumping from one server 2 another
2004-01-10 kl. 00.21 skrev Richard Huxton: Can't get the sudo -u user1 /usr/local/bin/pg_dump db1 | /usr/local/bin/psql -U user2 -h host2 db2 to work. Only thing that happens is that I get multiple passwordprompts, and then I gets told that the password is incorrect… You probably want a .pgpass file - see the section on libpq in the manuals (client interfaces / libpq / files) Hi and thanks for the tip! Have created my .pgpass-file, and is able to connect as well to my local server as to my remote server, each for them self. This: /usr/local/bin/psql -U user_local db_local and: /usr/local/bin/psql -U user_remote -h host_remote db_remote works fine. This, though, doesn't work: /usr/local/bin/psql -U user_local db_local | /usr/local/bin/psql -U user_remote -h host_remote db_remote Any tips, anyone? Sincerely Victor ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [GENERAL] insertion with trigger failed unexpectedly
On Monday 12 January 2004 05:57, [EMAIL PROTECTED] wrote: > Dear all, > i have a problem with insertion data and running post insert trigger > on it. > When i'm doing tests - everything is going well, but in > production when multiple records being inserted losses happend. OK - there must be something different happening with the live situation. Better post the CREATE TABLE, trigger code and a sample INSERT. PS - is the problem: 1. INSERT fails to raw table, and daily is not updated 2. INSERT fails to raw table, but daily is updated 3. INSERT works on raw table but daily is not updated -- Richard Huxton Archonet Ltd ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] Drawbacks of using BYTEA for PK?
On Sunday 11 January 2004 22:05, D. Dante Lorenso wrote: > David Garamond wrote: > > Are there any drawbacks of using BYTEA for PK compared to using a > > primitive/atomic data types like INT/SERIAL? (like significant > > performance hit, peculiar FK behaviour, etc). > > > > I plan to use BYTEA for GUID (of course, temporarily I hope, until > > PostgreSQL officially supports GUID data type), since it seems to be > > the most convenient+compact compared to other data types currently > > available. I use GUIDs for most PK columns. > > GUID? Isn't that really nothing more than an MD5 on a sequence? > > SELECT (MD5(NEXTVAL('my_table_seq'))) AS my_guid; I think the point of a GUID is it's supposed to be unique across any number of machines without requiring those machines to coordinate their use of GUID values. I think the typical approach is to use something like: hash_fn( network_mac_address || other_hopefully_unique_constant || sequence_val ) and make sure that the probability of getting collisions is acceptably low. ISTR a long discussion a year or two back on one of the lists, for those that are interested. -- Richard Huxton Archonet Ltd ---(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] Case sensitivity
On Sunday 11 January 2004 09:29, Dario Ottaviano wrote: > I use postgres on a window server (IIS 5.1) > Is there anybody that knows if is possible to make postgres no case > sensitive in the manipulating data into tables/views? There's no general "case_sensitive = yes/no" flag. There are case-insensitive operators you can use though. -- Richard Huxton Archonet Ltd ---(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] Bug with rename bigserial column
On Sunday 11 January 2004 13:14, Nigel J. Andrews wrote: > On Sun, 11 Jan 2004, Richard Huxton wrote: > > On Saturday 10 January 2004 21:31, D. Dante Lorenso wrote: > > > I just ran into a dump/restore problem with a bigserial column > > > on a renamed table. > > > > [snip] > > > > > I've corrected the problem manually, but it does seem like a bug > > > somewhere. > > > > Sounds like a bug. You might want to have a look and see if it's > > restoring the value of the old or new sequence. > I think previous discussions on this couldn't decide between not renaming > the underlying sequence and the one where the sequence is also renamed when > the table is. > > Of course in this instance it's slightly different in that it does sound > like a bug of the dump/restore process with the not renaming sequence > behaviour employed. Yep - it sounds like the column definition is doing one thing, while the sequence definition is doing the other. -- Richard Huxton Archonet Ltd ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] Hierarchical queries
Thanks Graeme! MG> http://marc.theaimsgroup.com/?l=postgresql-sql&m=106739176106877&w=2 But this function is still returning only a subtree and in addition it have a bug when calling it like SELECT * FROM crawl_tree(0,0); You will always get ERROR: out of memory But this function is clear enough to write some additional code :) regards, Anton ---(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