[SQL] Database consistency after a power shortage

My question is regarding a potential situation: I have a program that inserts values on 3 tables linked to each other. My program is used in a POS. In this specific case, the program has to update the tables header_invoice, detail_invoice and payments_x_header_invoice. In a normal operation, the

[SQL] select result into string's array

this?? May I choose another way? Thanks in advance Alberto, -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql

Re: [SQL] select result into string's array

Dmitriy Igrishin wrote: Hello. You should use an array constructor: DECLARE m_array text[]; [..] BEGIN FOR m_array IN SELECT ARRAY[col_1, col_2, col_N] FROM my_table LOOP [..] END LOOP; Regards, Igrishin Dmitriy. 2009/10/9 Alberto Asuero Arroyo albertoasu...@gmail.com

[SQL] Encrypt data type LO

this with me. Regards. Ing. Carlos Alberto Piña Uribe Consultoría y Desarrollo KEBIR Infraestructura Tecnológica [EMAIL PROTECTED]

[SQL] FUNCTIONS PROBLEM

Hi. i have a function and i need to return 4 fields but not work, any idea , please thank mario ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

[SQL]

HI, i have a following function., but not work. CREATE or replace FUNCTION get_nombre(numeric,numeric,text) RETURNS setof cumaalu AS ' SELECT cunomalu,cuappalu,cuapmalu FROM cumaalu WHERE siempalu = $1 and cusesalu = $2 and curutalu = $3; ' LANGUAGE SQL; the error say

Re: [SQL] [HACKERS] why is postgres estimating so badly?

AND part.name LIKE '%green%' It's difficult for the planner to produce a decent estimate for the selectivity of an unanchored LIKE clause, since there are no statistics it can use for the purpose. We recently changed FIXED_CHAR_SEL in src/backend/utils/adt/selfuncs.c from 0.04 to 0.20,

[SQL] why is postgres estimating so badly?

I have a query and estimations and results don´t look similar, here is explain analyze: NOTICE: QUERY PLAN: Sort (cost=12443.90..12443.90 rows=1 width=93) (actual time=505331.94..505332.67 rows=175 loops=1) - Aggregate (cost=12443.88..12443.89 rows=1 width=93) (actual

Re: [SQL] [HACKERS] please help on query

- Original Message - From: Masaru Sugawara [EMAIL PROTECTED] To: Luis Alberto Amigo Navarro [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, July 15, 2002 6:15 PM Subject: Re: [SQL] [HACKERS] please help on query Sorry, I don't know the reason. I need more info. Can you show

Re: [SQL] [HACKERS] please help on query

- Original Message - From: Masaru Sugawara [EMAIL PROTECTED] To: Luis Alberto Amigo Navarro [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, July 14, 2002 2:23 PM Subject: Re: [SQL] [HACKERS] please help on query This is the output: Aggregate (cost=0.00..647161.10 rows=600122

Re: [SQL] [HACKERS] please help on query

The cost is now only 1141741215.35 compared to 2777810917708.17 before; this is an improvement factor of more than 2000. So what's your problem? ;-) Servus Manfred In fact planner is estimating incredibly badly, it took only 833msecs now runs perfectly I'm going to keep on asking

Re: [SQL] [HACKERS] please help on query

width=4) - Seq Scan on lineitem (cost=0.00..08.25 rows=6001225 width=0) where might be my mistake Thanks and regards - Original Message - From: Manfred Koizar [EMAIL PROTECTED] To: Luis Alberto Amigo Navarro [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, July

Re: [SQL] [HACKERS] please help on query

might be excessive. Any other idea? Thanks And Regards - Original Message - From: Jakub Ouhrabka [EMAIL PROTECTED] To: Luis Alberto Amigo Navarro [EMAIL PROTECTED] Cc: Manfred Koizar [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, July 12, 2002 1:50 PM Subject: Re: [SQL] [HACKERS