On Tue, May 5, 2009 at 9:10 AM, DaNieL..! wrote:
> Hi guyst.. thanks for the replies, really, them make me suppose that
> all what i've learned of sql from mysql can be wrong..
Replace "all" with "much" and you pretty much got the problem with
using MySQL for your first database experience. (Not
On Mon, May 4, 2009 at 12:53 PM, Jasen Betts wrote:
> select exp(sum(ln( thiscolumn ))) from foo;
Keep in mind that it won't work when the table containts negative
numbers, though (or zeros, but since in this case the product is also
zero, it doesn't matter)
--
Sent via pgsql-general mailing li
On Thu, Apr 30, 2009 at 3:00 PM, paulo matadr wrote:
> Hi all,
> my database entry in mode recovery,
> analyzing my pg_log I seem this:
> system logger process (PID 6517) was terminated by signal 9
> background writer process (PID 6519) was terminated by signal 9
> terminating any other active ser
On Sat, Apr 25, 2009 at 2:51 AM, Alvaro Herrera
wrote:
> In that case you can create a partial unique index:
>
> create index foo on cdr_ama_stat (abonado_a, abonado_b, fecha_llamada,
> duracion) where processed = 2;
Of course, the unique is missing in this one:
CREATE UNIQUE INDEX foo ON cdr_am
On Thu, Feb 19, 2009 at 7:08 PM, c k wrote:
> As
> all rows are rewritten(newly inserted with changed column value), the
> indices must be updated accordingly and this may take more time?
I'd think so, but I'm no expert.
If you have many and frequent updates, it might be worthwhile to
adjust the
On Tue, Feb 10, 2009 at 7:04 PM, Inigo Barandiaran
wrote:
> I've read that if I define an environment variable like SET
> PGPPASSWORD=MyPosgresUserPassword, both calls dont ask for password. I've
> tested this variable in different platforms and does not work.
> Do you know how so solve it?
As yo
(Sorry for the forward, I forgot to CC the list)
On Wed, Dec 17, 2008 at 9:38 AM, Herouth Maoz wrote:
> and for non-transaction tables (ones that have records that might
> change but don't accumulate based on time) it's DELETE without WHERE.
In that case, you are better off using TRUNCATE instea
On Thu, Nov 6, 2008 at 8:49 AM, Rafal Pietrak <[EMAIL PROTECTED]> wrote:
> One comment I'd like to make as total lamer on the subject, is that the
> assumption on SELECT (that it's not firing triggers), could potentially
> be resolved by a *global* or "database" configuration option - once
> select
On Fri, Oct 31, 2008 at 04:36:02PM -0400, Eric Schwarzenbach wrote:
> As I explained already (no pun intended) running the query using EXPLAIN
> makes the wild variation go away. So I cannot get explain results for a
> fast and for a slow execution.
EXPLAIN only determines and outputs the query pl
On Wed, Oct 1, 2008 at 5:54 PM, Reg Me Please <[EMAIL PROTECTED]> wrote:
> Hi all.
>
> Is there a way to have (sub)transactions within a function body?
> I'd like to execute some code (a transaction!) inside a function and later
> decide whether that transaction is to be committed or not.
You coul
On Wed, Oct 1, 2008 at 6:23 PM, Glyn Astill <[EMAIL PROTECTED]> wrote:
> I presume it's issuing some sort of commit or rollback without a begin,
> however the programs authors are telling me that's not the case and their
> software is not at fault.
Of course their software can't be at fault, as
You can use a unique index:
CREATE UNIQUE INDEX idx_foo_unique_upper_x_upper_y ON foo
(UPPER(x), UPPER(y));
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Tue, Jul 8, 2008 at 12:06 AM, Keaton Adams <[EMAIL PROTECTED]> wrote:
> An analyze is run on the tables every day (even several times a day because
> they are updated very frequently) and a vacuum analyze is run on the
> weekends. I also tried to run an analyze specifically on the customer_id
>
On Thu, Apr 10, 2008 at 4:40 PM, Pavan Deolasee
<[EMAIL PROTECTED]> wrote:
> On Thu, Apr 10, 2008 at 7:18 PM, Ivano Luberti <[EMAIL PROTECTED]> wrote:
>
> I think that's because Postgres does not have deferred constraint checks.
I believe it does. See
http://www.postgresql.org/docs/8.3/interactiv
Hello,
I need to write a stored procedure that does look something like this:
CREATE FUNCTION foo() RETURNS SETOF BIGINT LANGUAGE plpgsql AS $$
DECLARE
result RECORD;
BEGIN
EXECUTE 'CREATE TEMP TABLE foo (id int,...)';
-- Insert something into foo depending on contents of the data
Hello,
I need to write a stored procedure that does look something like this:
CREATE FUNCTION foo() RETURNS SETOF BIGINT LANGUAGE plpgsql AS $$
DECLARE
result RECORD;
BEGIN
EXECUTE 'CREATE TEMP TABLE foo (id int,...)';
-- Insert something into foo depending on contents of the database
Hi,
I have some problems supporting "translatable columns" in a way that
is both efficient and comfortable for the programmer who has to write
SQL-Queries (we use iBatis)
Suppose I have a simple table that contains an id field and (amongst
others) a name field. Let's call this table foo. The name
Hi,
I have some problems supporting "translatable columns" in a way that
is both efficient and comfortable for the programmer who has to write
SQL-Queries (we use iBatis)
Suppose I have a simple table that contains an id field and (amongst
others) a name field. Let's call this table foo. The name
18 matches
Mail list logo
