;d affect the environment passed to psql. I'm suspicious of
his solution because I'd have thought the terminal program would set up
the right environment ... but you might as well try it.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
gt; test1_point_get_id_test1_poly();
I think you need that to be a BEFORE insert or update trigger. In
an AFTER trigger, it's too late to affect the stored row.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
perfectly clear that a column alias is an identifier just like any
other. And you'd still be paying a large part of the application
breakage costs, because the identifiers coming back in query descriptors
are one of the main ways applications would notice such a change.
e. Postgres settled on this behavior fifteen years ago,
and we're not changing it now.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
this in HEAD
(at least with a GIN index; GIST seems much less able to do well with
short prefixes). What PG version are you testing?
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
or text[], etc). Now you can build the array client-side and not need
a new statement for each different number of comparison values. If
you're not into prepared statements, this may not excite you, but some
people find it to be a big deal.
regards, tom lane
--
Se
perfectly legal outer reference to qry.setid.
Probably not one of SQL's better design features, since it confuses
people regularly; but it's required by spec to work like that.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.or
nied for relation entities
What's failing is that the *owner of the view* needs, and hasn't got,
select access on the entities table. This is a separate check from
whether the current user has permission to select from the view.
Without such a check, views would be a security hole.
t of updated rows
won't be very meaningful, and RETURNING values likewise. If that's a
problem for you, you could use an AFTER trigger instead, which will be a
little slower but it hides the deletes behind the scenes. (Note: a
DELETE issued in a trigger is a separate query, which is why
ts, so in general there's no way to be
sure which one would process a particular row first.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
URNS TABLE function, this should be good enough. With simpler
functions you might have to insert OFFSET 0 into the sub-select to keep
the planner from "flattening" it into the upper query and producing the
same multiple-evaluation situation.
regards, tom lane
--
Sent
vent_agg b
> (cost=0.00..10.27 rows=1 width=1694)"
> " Output: b.date_id, b.vcset, b.eventcountset, b.eventvalueset"
> " Index Cond: ((b.date_id >= 20120228) AND (b.date_id <=
> 20120228))"
I'd expect that to happen autom
rying to achieve is "date_trunc('day', start_date at time zone 'utc')"
http://www.postgresql.org/docs/9.2/static/functions-datetime.html#FUNCTIONS-DATETIME-EXTRACT
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
That sounds like a pgAdmin bug. You should report it in the pgAdmin
mailing lists.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
"Sergio C." writes:
> We started the cluster up with this command:
> ./initdb -D /usr/local/postgre/data -E UTF8 -U sir
That doesn't prove anything about the specific database where you're
having the problem ...
regards, tom lane
--
Sent
more
than speculate.
> PostgreSQL 8.4.1 on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC) 3.4.6
> 20060404 (Red Hat 3.4.6-10), 64-bit
You do realize this is about 3 years out of date? The 8.4 series is up
to release 8.4.13, and a lot of those updates contained fixes for
serious bugs.
n though some of them have
names containing the word ROW for historical reasons. I don't see how
you'd read it to imply that there are no finer-grained locks anywhere in
Postgres.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.or
entation)
Sorry, that wiki page is just blue-sky speculation. If the feature were
supported, you would find it in the main documentation.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.p
is coming
from a trigger function or some such? In any case, we can't help you.
You need to identify what layer of software it's coming from, and
complain to the appropriate people.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
Wayne Cuddy writes:
> On Wed, Aug 08, 2012 at 12:23:22PM -0400, Tom Lane wrote:
>> If it only complains once per file name, this is expected behavior when
>> somebody drops a table just before the checkpoint mechanism tries to
>> fsync it. (If the failure were to rep
ng
more interesting.) It does seem a bit odd that only fsm files are being
complained of, though.
What PG version is that exactly?
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
way of representing the ranges as indexable objects.
In 9.0 or 9.1, probably the best way is to use contrib/seg/ to
represent the ranges as line segments. 9.2 will have a cleaner
solution, ie range types.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@
Volatile functions in the
select list are an optimization fence. That particular function looks
like it should be IMMUTABLE instead, since it depends on no database
state. If it does look at database state, you can probably use STABLE.
http://www.postgresql.org/docs/9.0/static/xfunc-volatility.ht
Sergey Konoplev writes:
> On Thu, Jul 19, 2012 at 6:52 PM, Tom Lane wrote:
>>> Now I was wondering if a DELETE statement could be rewritten with the same
>>> "strategy":
>> Not at the moment. There have been discussions of allowing the same
>> table
ement could be rewritten with the same
> "strategy":
Not at the moment. There have been discussions of allowing the same
table name to be respecified in USING, but there are complications.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgre
ficant digits, so that numeric gives a
* result no less accurate than float8; but use a scale not less than
* either input's display scale.
*/
I wouldn't necessarily claim that that couldn't be improved on,
but that's what it does now.
rega
longer text.
You'd need to tell the readline people about that one.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
rom func(5) as foo(id);
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
9.1/static/charset.html
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
e cast" is a poor choice of words here,
since the types *can* be cast if you try. Would it be better if the
message said "cannot be cast implicitly to type foo"? We could also
consider a HINT mentioning use of USING.
regards, tom lane
--
Sent via pgs
n to invent nonstandard syntax for this.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
e this:
regression=# select 1/ from foo;
ERROR: syntax error at or near "from"
LINE 1: select 1/ from foo;
^
If you're using something so old that it doesn't do that, the answer
is to update.
regards, tom lane
--
Sent via pgsql-sql mai
cing non-machine-readable files, so the fact that it doesn't have
an option for this doesn't bother me.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
eadline callback interface, though maybe
if somebody got ambitious they could improve it.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
eird
user-defined version of substr() or ~ that isn't immutable?
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
-sorts the data before it gets to the Aggregate
step.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
XECUTE. The latter, if not done as
superuser, would at least ensure you didn't accidentally break any
functions you don't own.
In either case, I'd practice against a test copy of the database before
doing this live ...
regards, tom lane
--
Sent via pgsql
sure
I see much point in that.
In the longer term it might be nicer if the system catalogs did record
inherited-ness of defaults (and then pg_dump could rely on that info
instead of guessing); but that would be a far more invasive change.
regards, tom lane
--
Sent via p
ch_path settings.
It's possible that you have actually found a pg_dump bug, but if so
you'll need to submit a complete test-case exhibiting the bug.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
er sensibly
be added to it.
Possibly the documentation should be tweaked to mention the
number-followed-by-identifier case.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
Gerardo Herzig writes:
> So, what happens, when a plsql function is excecuted, it takes is own
> enviroment variables, or something like that?
No, but it probably cached a plan from an execution before you changed
join_collapse_limit ...
regards, tom lane
--
Se
actor on 10.
increase join_collapse_limit, perhaps?
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
u were already told
last week:
http://archives.postgresql.org/pgsql-general/2011-12/msg00899.php
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
ent-side
frameworks that will do it for you, or you can roll your own easily
enough. So we do not see it as a big deal that the database server
itself doesn't act that way.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make ch
NEST, but with the code that
deals with concurrent row updates.
I've committed a fix, which will appear in next week's updates.
Thanks for the report and test case!
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
tgres backends, and it's really hard to believe that unnest would be
affected by what's happening in other server processes.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
nor release of your Postgres branch, update
and see if it goes away. If not, please file a bug report with
sufficient information to reproduce the problem by hand (ie, the
problem query plus schema+data sufficient to run it against).
regards, tom lane
--
Sent via pgsql-sq
care to read the rest of 4.1.2 while at it.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
of problem. But for
now, it's going to be painful.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
Steve Northamer writes:
> So my questions are: 1) How do we cause the paymentcalc function to be
> executed only once?
In recent versions, I think marking it volatile would be sufficient.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgres
/9.0/static/plpgsql-implementation.html
I wouldn't really recommend turning off the conflict detection, though.
We put it in because of the number of hours people had wasted on
unrecognized conflicts.
regards, tom lane
--
Sent via pgsql-sql mailing l
d likely work all right anyway, since
there is no reason for a plain SELECT FROM to do anything except scan
the subquery once. But if you did a join, say, watch out!)
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
Emi Lu writes:
> On 08/30/2011 11:24 AM, Tom Lane wrote:
>> select * from tablename
>> where not (col1 ~~* any(array['str1%', 'str2%'... 'strN%']));
> If next version could have "not ilike ('', '')" added into wi
ame
where not (col1 ~~* any(array['str1%', 'str2%'... 'strN%']));
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
newid;
EXIT WHEN newid IS NULL;
out := out || test (newid);
END LOOP;
RETURN out;
END;
$BODY$
LANGUAGE 'plpgsql' VOLATILE;
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
expect the sub-statements
to yield any duplicates, or don't care about seeing the same row twice
in the output, you should consider UNION ALL instead of UNION.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
Nikolay writes:
> select testtable.name from testtable; // returns strange result.
See
http://archives.postgresql.org/pgsql-bugs/2010-10/msg00269.php
This will change in 9.1:
http://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=543d22fc7
regard
major platforms seem to offer
one.
Also, just to be perfectly clear: this is not Postgres' fault, it's
just sorting the way strcoll() says to. You'll get the same sort
order from the command-line sort(1) program, if you feed it the same
data in the same locale environment.
bilities from SQL:99, notably
6) In ISO/IEC 9075-2:1999, a , , or could consist of a . None of those three elements can consist of a in this edition of ISO/IEC 9075.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make chang
ECT, INSERT, UPDATE, DELETE.)
There's been occasional speculation about changing that, but it would
take a significant amount of work I think.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
that join_collapse_limit
or from_collapse_limit could be in play?
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
ry order", which
I believe includes ignoring spaces in the first pass. You might be
happier using "C" collation. Unfortunately that requires re-initdb'ing
your database (as of existing PG releases).
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsq
ATE setting"? Non-C locales often have truly bizarre
sorting rules.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
y
Windows, so can't help you much further than that.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
e better
luck asking on pgsql-jdbc.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
manuel antonio ochoa writes:
> How can I solve this problem :
> FATAL: invalid cache id: 19
There was a bug with that symptom in 9.0.0 and 9.0.1 ... if you're
running one of those versions, update.
regards, tom lane
--
Sent via pgsql-sql mailing list
; select ...
Leave out the second "with recursive". WITH introduces a list of
name-AS-subselect clauses, not just one.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
olumns: 223
The example function works okay for me in psql. I think this is
actually a question about how to deal with such cases through the JDBC
driver, so I'd suggest asking on the pgsql-jdbc list. (Perhaps in a
less messy format this time, and could we as
Rob Sargent writes:
> On 04/13/2011 09:09 AM, Tom Lane wrote:
>> Anish Kejariwal writes:
>>> (select store_id, avg(sales) sales
>>> from store
>>> where group_id in(select $1[i] from generate_subscripts($1, 1) g(i))
>> Seems like a pretty brute-force
it's at least easier to
write.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
ing it like this instead:
SELECT * from unnest(ARRAY[1,2,3]) a, unnest(ARRAY[4,5,6,7]) b;
This has saner behavior and is less likely to leak memory. Not to
mention less likely to be deprecated or de-implemented altogether
in the far future.
regards, tom lane
--
Sent
text
> _varchar
Those are array types. The normal convention is that foo[] is named
"_foo" under the surface.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
ot return "{null}, {123}" but no result at all.
Yes, because regexp_matches returns a rowset of zero or more results.
The fine manual suggests putting it in a sub-select if what you want
is a null or a single result:
SELECT ... , (SELECT regexp_matches(...)) FROM ...
int of view it would be actively damaging: providing
standardized views would reduce customer lock-in, by making applications
more portable to other DBMSes. The pain the OP is feeling is a
marketing advantage, so far as Oracle is concerned.
regards, tom lane
--
Sent via
_hits
> where length(sourceid) > 5);
That seems like a pretty bizarre operation to apply to a number. Why
not "where sourceid > 9"? Or maybe "where abs(sourceid) > 9"
would be better.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
bers of rows. Converting to NOT EXISTS might
help some, though I don't remember right now how smart 8.3 is about
either.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
ses and then define some variable that doesn't
actually have any underlying loadable module.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
lementation.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
T: PL/pgSQL function "ventas_imp_a_ventas_cab"
The function that's lacking a RETURN is not the one you're showing us.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
=?iso-2022-jp?B?GyRCQ2ZAbiEhQD81LhsoQg==?= writes:
> I'm trying to use like 'xx%' search on Text[] column.
> I thought it uses index scan. But actually it uses seq scan.
> Why?
Those ANY expressions are not indexable.
regards, tom lane
--
Se
p?
SELECT ... WHERE
((col1 is not null)::int +
(col2 is not null)::int + ...
(col20 is not null)::int) = 1 -- or > 1
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
syntax (with parens) for
any of the new options.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
ht match one of the NULLs, because NULL means "unknown" in this
context). Newbies get caught by that all the time :-( ... it's not one
of SQL's better features.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
entation of a
sequence. Why don't you use a real sequence object and nextval()?
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
"John Lister" writes:
> Is it possible to obtain the difference between just the minimum price and
> the next one up per product,
If you're using >= 8.4, try a window function. LEAD or LAG ought to
do it.
regards, tom lane
--
Sent via pgsql
eve you can split backslash commands across lines.
> When I remove the linefeeds I don't get errors but it does not import
> anything.
You wanted pstdin, not stdin.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to
all.
I think you can get the effect you're after using \copy ... from pstdin.
See the psql man page.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
specifically the LC_COLLATE
setting. If you want "plain ASCII" sort order, you need to switch to
C locale.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
least consider using a newer version for development. That has its
own hazards of course, like accidentally using features that don't exist
in 7.4, but it could save you a lot of time in cases like this.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgr
hing, so I'd
advise against using it if you can get decent performance with EXISTS.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
se notes it appears that the behavior of SIMILAR
> TO has changed in pg9.0. My question is, how do I modify my code so
> that it works in 9.0?
Drop the ^ and $; they are incorrect for SIMILAR TO.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postg
need to put the DISTINCT and the ORDER BY in separate query levels,
like this:
select * from
(Select Distinct VehicleMake, VehicleModel
From VehicleYearMakeModelTrim) ss
Order by random()
Limit 10;
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sq
it postgresql-dev or something else).
It should certainly be available somewhere from them --- if not,
file a packaging bug report.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresq
s manually if it turns
out that join order does matter.
Basically, if you're gonna join that many relations, it's gonna cost ya
:-(. Star schemas are overrated IMO.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
ck of any very sane way to define the behavior is the main argument
for deprecating SRFs in the targetlist.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
Nathan Grange writes:
>> Or if this is a bug with 9.0, what actions do I take to make the
>> PostgreSQL team awares?
I think you already did ;-)
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscr
"Steve" writes:
>> Von: Tom Lane
>> It's unlikely to make enough difference to be worth the trouble.
>>
> Making a quick sort is ultra easy in C. Anyway... is there a
> difference in the speed of the query with pre-sorted values or not?
> If there is
> but what about several thousand of values? Would sorting them and sending the
> SQL query with ordered data influence the speed of the query?
It's unlikely to make enough difference to be worth the trouble.
regards, tom lane
--
Sent via pgsql-sql mailing l
n't recommend it as a production setting.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
ELECT list.)
You could try something like
select my_expensive_function(...), etc, etc from
(select * from some-tables order by foo limit n) ss;
where the inner select list just pulls the columns you'll need in
the outer calculations.
regards, tom lane
--
1 - 100 of 2610 matches
Mail list logo
