Hi Tom,
On Thu, 2007-02-08 at 23:24 -0500, Tom Lane wrote:
> Certainly, but your other concerns don't follow from that. The issue at
> hand here is whether it's worth expending cycles on every query to try
> to detect a situation that only holds for a few.
Those where George's concerns, but I wa
unsubscribe
We won't tell. Get more on shows you hate to love
(and love to hate): Yahoo! TV's Guilty Pleasures list.
http://tv.yahoo.com/collections/265
---(end of broadcast)-
Joe <[EMAIL PROTECTED]> writes:
> Are you saying the planner is datatype-agnostic
Certainly, but your other concerns don't follow from that. The issue at
hand here is whether it's worth expending cycles on every query to try
to detect a situation that only holds for a few.
Hi Tom,
On Thu, 2007-02-08 at 22:50 -0500, Tom Lane wrote:
> There's a datatype abstraction issue involved: what does it take to
> prove that "x >= 10 AND x <= 10" is equivalent to "x = 10"? This
> requires a nontrivial amount of knowledge about the operators involved.
> We could probably do it f
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I think the principle here is that the system is not gonna waste cycles
> on dumb queries. Supposedly, morphing "foo BETWEEN 10 and 10" into
> "foo=10" is not a trivial transformation, and it'd impose a planning
> cost on all non-dumb BETWEEN queries.
George Pavlov wrote:
> the basic question i have is fairly clear though: why saying "where x =
> 10" should be different (in ANY cicumstance, not just mine) from saying
> "where x between 10 and 10" or from "where x in (select ... /* some
> query that returns 10 */)" ???
I think the principle h
> > BYs on user_id and various subqueries, but my basic thought is that
> > should not really matter...
>
> You're unlikely to get any useful comment on this when you have not
> shown any of those details, nor even an EXPLAIN.
yes, i know. i guess i was partially just venting. sorry. the problem
"George Pavlov" <[EMAIL PROTECTED]> writes:
> there is, admittedly, substantial complexity inside v_foo, with GROUP
> BYs on user_id and various subqueries, but my basic thought is that
> should not really matter...
You're unlikely to get any useful comment on this when you have not
shown any of t
A pl/pgsql function can do this easily. Something like this (not
tested):
create or replace function dup_my_table(old_key text, new_key text)
returns text as
$$
declare
rec my_table;
begin;
select into rec * from my_table where key_field = old_key;
rec.key_field = new
all my SQL-writin' life i have been assuming that expressions like =,
IN, BETWEEN in the WHERE clause are, in the most general sense,
alternative ways of doing the same things. i am hitting some very very
bizarre results in PGSQL:
i have a (very involved) view, say v_foo, largely optimized to be
q
On 8 Feb 2007 at 10:59, Demel, Jeff wrote:
> I don't have a problem with doing this in our development environment,
> but when we go to move it onto the live production box, with all the
> live data and current custom settings, will a re-install cause issues?
> Data loss is unacceptable, of course
That works like a charm. Thanks, Alvaro!
-Jeff
-Original Message-
From: Alvaro Herrera [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 08, 2007 1:22 PM
To: Demel, Jeff
Cc: pgsql-sql@postgresql.org
Subject: Re: [SQL] COPY FROM - force a value
Demel, Jeff wrote:
> Is there a way to f
On 1/30/2007 3:17 PM, Jamie A Lawrence wrote:
Just a datapoint:
SQL*Plus: Release 10.1.0.3.0 - Production on Tue Jan 30 15:15:49 2007
Copyright (c) 1982, 2004, Oracle. All rights reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.1.0.3.0 - Production
With the Partition
Demel, Jeff wrote:
> Is there a way to force a value when you're doing a COPY FROM, importing
> a file into a table?
>
> Here's my query as it is now:
>
> COPY filetable (value1, value2, value3, value4, forcevalue1,
> forcevalue2)
> FROM 'C:\\InsertFiles\\thisfile.txt'
> WITH DELIMITER AS ' '
unsubscribe
---(end of broadcast)---
TIP 1: 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
Is there a way to force a value when you're doing a COPY FROM, importing
a file into a table?
Here's my query as it is now:
COPY filetable (value1, value2, value3, value4, forcevalue1,
forcevalue2)
FROM 'C:\\InsertFiles\\thisfile.txt'
WITH DELIMITER AS ' '
;
The file only contains data for
I increase the "max_stack_depth" and the In statemen run OK.
I don't know if it is good to put this variable as big as possible or as the
manual report (using ulimit -s) to put the larger stack capacity of
Operational System.
Ezequias
2007/2/8, Andrew Sullivan <[EMAIL PROTECTED]>:
On Thu, Feb
"Ezequias Rodrigues da Rocha" <[EMAIL PROTECTED]> writes:
> Now the sql is OK but now I have the following error:
> ERROR: stack depth limit exceeded
> SQL state: 54001
> Hint: Increase the configuration parameter "max_stack_depth".
> In the previous e-mail I hide the numbers of itens of my set
>
On Thu, Feb 08, 2007 at 03:13:16PM -0200, Ezequias Rodrigues da Rocha wrote:
>
> Any suggestion instead of change my max_stack_depth ?
Well, I suppose you could put the numbers in a temp table an NOT IN
on that.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
The fact that technology doesn't work is
At 17.50 08/02/2007, Ezequias Rodrigues da Rocha wrote:
>Hi list,
>
>Could someone tell me what is wrong on this statement ?
>
>Start Transaction
>delete from base.something
>where
>id in(
>41503,
>41504,
>41505,
>41506,
>41507,
>41508,
>41509,
>41510,
>41511,
>41512,
>41513,
>41514,
>41515,
>41516
Now the sql is OK but now I have the following error:
ERROR: stack depth limit exceeded
SQL state: 54001
Hint: Increase the configuration parameter "max_stack_depth".
In the previous e-mail I hide the numbers of itens of my set
(in(234,12332,1232,) actually I have more than 36000 subsets of
I don't have a problem with doing this in our development environment,
but when we go to move it onto the live production box, with all the
live data and current custom settings, will a re-install cause issues?
Data loss is unacceptable, of course, but it would also be nice if we
don't have to jugg
Hi Ezequias,
On Thu, 2007-02-08 at 14:50 -0200, Ezequias Rodrigues da Rocha wrote:
> Hi list,
>
> Could someone tell me what is wrong on this statement ?
>
> Start Transaction
The above should read
begin;
> delete from base.something
> where
> id in(
> 41503,
> 41504,
> 41505,
> 41506,
> 415
Hi list,
Could someone tell me what is wrong on this statement ?
Start Transaction
delete from base.something
where
id in(
41503,
41504,
41505,
41506,
41507,
41508,
41509,
41510,
41511,
41512,
41513,
41514,
41515,
41516,
41517,
41518,
41519,
41520,
41521,
41522,
41523,
41524,
41525,
41526,
41527
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> I need to create some nearly identical copies of rows in
> a complicated table.
>
> Is there a handy syntax that would let me copy a existing row,
> but get a new primary key for the copy?
http://people.planetpostgresql.org/greg/index.php?/ar
Michael Fuhr <[EMAIL PROTECTED]> writes:
> On Thu, Feb 08, 2007 at 10:32:25AM -0500, Tom Lane wrote:
>> My advice is not to try to execute multiple commands in the same EXECUTE
>> string --- if we were going to do anything to "fix" this, I think it
>> would be along the lines of enforcing that advi
On Thu, Feb 08, 2007 at 10:32:25AM -0500, Tom Lane wrote:
> My advice is not to try to execute multiple commands in the same EXECUTE
> string --- if we were going to do anything to "fix" this, I think it
> would be along the lines of enforcing that advice. Trying to make the
> world safe for it do
Michael Fuhr <[EMAIL PROTECTED]> writes:
> Using separate calls to SPI_exec() works. Using a single call to
> SPI_exec() works if the index is on (t) instead of (lower(t)):
> SPI_exec("CREATE TABLE foo (t text); CREATE INDEX foo_idx ON foo (t)", 0);
It's only by chance that it works in that case
unsubscribe
--
Adrien LEBRE
Projet PARIS / XtreemOS
IRISA, Rennes, France
+33(0)2 99 84 22 39
http://www.xtreemos.org
---(end of broadcast)---
TIP 9: In versions below 8.0
unsubscribe
On Thu, Feb 08, 2007 at 11:14:33AM -0300, Alvaro Herrera wrote:
> Michael Fuhr wrote:
> > The error appears to happen for anything that uses SPI. A C function
> > that executes the following fails with the same error:
> >
> > SPI_exec("CREATE TABLE foo (t text); CREATE INDEX foo_idx ON foo
> > (
Michael Fuhr wrote:
> On Wed, Feb 07, 2007 at 02:43:13PM -0800, Greg Wittel wrote:
> > I'm having a strange problem with a PL/PGSQL query that executes some
> > dynamic SQL code. The code basically creates a dynamically named table,
> > some indexes, etc.
> >
> > The problem seems to be the an
Unsubscribe
Susan Evans
Haywood County Schools
NCWISE Coordinator
216 Charles Street
Clyde, NC 28721
828-627-8314 (Phone)
828-627-8277 (Fax)
216 Charles Street
Clyde, NC 28721
---(end of broadcast)---
TIP 6: explain analyze is your friend
unsubscribe
---(end of broadcast)---
TIP 1: 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
On Wed, Feb 07, 2007 at 02:43:13PM -0800, Greg Wittel wrote:
> I'm having a strange problem with a PL/PGSQL query that executes some
> dynamic SQL code. The code basically creates a dynamically named table,
> some indexes, etc.
>
> The problem seems to be the an index expression. If I remove it
Ahh,
Forgot about trunc() in the midst of all this ...
Thank you guys again !
Aarni
On Thursday 08 February 2007 12:06, Bart Degryse wrote:
> Use trunc instead of round.
> Also take a look at ceil and floor functions
>
> >>> Aarni Ruuhimäki <[EMAIL PROTECTED]> 2007-02-08 11:01 >>>
>
> On Thursd
Use trunc instead of round.
Also take a look at ceil and floor functions
>>> Aarni Ruuhimäki <[EMAIL PROTECTED]> 2007-02-08 11:01 >>>
On Thursday 08 February 2007 00:09, you wrote:
> select extract(epoch from (timestamp '2007-02-07 16:24:00' -
timestamp
> '2007-02-05 13:00:01'))/60 as minutes;
>
>
On Thursday 08 February 2007 00:09, you wrote:
> select extract(epoch from (timestamp '2007-02-07 16:24:00' - timestamp
> '2007-02-05 13:00:01'))/60 as minutes;
>
> minutes
> --
> 3083.983
> (1 row)
>
> select round(extract(epoch from (timestamp '2007-02-07 16:24:00' -
On Thursday 08 February 2007 09:19, Bryce Nesbitt wrote:
> >
> > INSERT INTO mytable SELECT * FROM mytable WHERE pk = 123;
> >
> > Or something close to that... I suspect if you changed the '*' to the
> > columns you wanted you could also work in the other columns you want
> > to change as well...
Demel, Jeff wrote:
Can this be installed easily on Windows?
Try re-running the installer, it should let you tick various options to
install from contrib.
--
Richard Huxton
Archonet Ltd
---(end of broadcast)---
TIP 5: don't forget to increa
40 matches
Mail list logo
