ients try
to remove dead line pointers? At least not unless they're also pruning the
page due to an insert or update anyways?
Fundamentally it does seem like we want to rotate vacuum's work-load. What
we're doing now is kind of backwards.
--
Gregory Stark
EnterpriseDB
-ahead. But I fear that would be quite hard on a production system with
the amount of noise from other i/o. It's hard enough on an idle machine with
synthetic benchmarks.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's Slony Rep
Should this function be replaced with one which allows returning a typmod as
well?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's On-Demand Production Tuning
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make cha
client as quickly as it can consume them.
Now I'm not sure anyone's actually done any experiments to optimize libpq or
other drivers to stream data efficiently, so I'm not sure how much you would
really lose in practice today.
--
Gregory Stark
EnterpriseDB ht
really work if you can start a new portal while the
outer portal is actually running on the backend. If the driver tries to cache
the whole result set the programmer will be sad.
Back when I was doing PHP programming and I discovered that PHP's Postgres
driver didn't support this I thought
ea whether he knows what he's talking about with respect to
> mysql, but it's certainly 100% irrelevant to the Postgres datatype.
The rest of it seems to be pretty mysql-specific. Some of the problems are
universal such as making index inserts especially random and making clustering
upstream could apply then git would be able to update
submitters trees with just the patches they're missing (ie, skipping the
patches they submitted upstream or merging them cleanly)
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trained by Bruce Momjian - ask me
ems to me "trace_sql_*" would be nicer, much as we have
track_* guc parameters.
Though I also wonder if there's really any distinction here between "tracing"
and "logging" like log_explain_plan and so on. Perhaps we should keep the word
"trace" for a
es just to indicate it was just a
quick hack to demonstrate an idea. In this case the implementation details are
not so relevant as just whether we like the idea at all.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's Slony Replication support!
ix this for
> many applications?
Well there are other circumstances where this can arise
select "FOO" from (select col as foo from bar)
Not to mention temporary objects which are created and dropped inside
functions.
--
Gregory Stark
EnterpriseDB http://www.enterpris
n a mile of spec -- which seems
like the only point of fiddling with this. Breaking this would take as further
from spec-compliance than we are today.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's PostGIS support!
--
Sent via pgsql-hacke
That's a good idea, imho, I'll try to do that
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
tgres to make
this change. IIRC it was someone comparing strings like paths and usernames
and getting false positives because they were in a Turkish locale which found
certain sequences of characters to be insignificant for ordering. Someone
who's using a citext data type has obviously decided
"David E. Wheeler" <[EMAIL PROTECTED]> writes:
> do I need to worry about memory leaks in citext_eq, citext_ne, citext_gt,
> etc.,
yes
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!
--
Sen
*) str, VARSIZE_ANY_EXHDR(txt));
I thought your data type implemented a locale dependent collation, not just
a case insensitive collation. That is, does this hash agree with your
citext_eq on strings like "foo bar" <=> "foobar" and "fooß" <=> "fooss
that shouldn't happen, but perhaps there's some reason it can.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL
training!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.
be need to put a SELECT pg_sleep(10) between the two queries in the
first file you run so that it hasn't updated both tables and exited before the
second one even starts. But I'm just guessing since you haven't sent the
actual files you're running.
--
Gregor
'0')
I think what you're suggesting is making integer and floating point constants
like 0 and 0.1 be treated as "unknown" or perhaps a different kind of unknown,
"unknown integral type" and "unknown numeric type".
Personally I think the way it works
>> I'm inclined to think that we'd better turn that off by default,
>> since it's not looking like it's catching anything new.
Well at least it caught the bug that Mark was performance testing with a
--enable-cassert build :/
--
Gregory St
defined collations,
> which creates a problem for pg_dump.
Out of curiosity, what is a "user-defined collation"? Are there SQL statements
to go around declaring what order code points should be sorted in? That seems
like it would be... quite tedious!
--
Gregory Stark
Enterp
"review found problems with memory
management" so we can reprioritize it without rereading the emails for every
item.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!
--
Sent via pgsql-hackers mailing list
I think that was the one) and thought they
> could get the patent before someone actually tried selling them.
Surely a movie counts as "published"!?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trained by Bruce Momjian - ask me about EnterpriseDB&#
XMLCONCAT, COL_NAME_KEYWORD},
{"xmlelement", XMLELEMENT, COL_NAME_KEYWORD},
Just use the existing XML_P keyword. The "_P" just stands for "parser" to
disambiguate it (I'm not sure a bison keyword could conflict with anything...
but anyways...).
--
G
.
Note that we don't currently do batches for hash aggregates, only joins
currently.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's On-Demand Production Tuning
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
me, and even if it
> were, this is obviously an ineffective way to do it ;-)
> Any objections to that one?
If we're going to do it at all it should be once at startup (or config file
read or some event like that). But I think I agree that it's just not our
place at all and just de
rising for inline compressed data structures. I
wonder if it isn't worthwhile just for that case even if there's a further
cache behind it for repeated fetches of out-of-line data.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA
makes
the main difference there. I don't know much about the two programs, what
makes you think one is more of a go-it-alone style of development than the
other?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trained by Bruce Momjian - ask me about EnterpriseDB
h doesn't really exist -- immutable
doesn't mean it might not throw errors, for example).
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's PostGIS support!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
ns. In which
case they never sit globally visible for very long but having the xmin/xmax in
the index might avoid having to do a heap access for tuples which haven't been
committed yet.
As you seem to realize there has been a lot of discussion in this area
already. The visibility m
#x27;t find the message for the later commits but they weren't backpatched to
8.3 so unless you're using HEAD you won't get properly working timezones for
post-2038
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA ser
"Hans-Juergen Schoenig" <[EMAIL PROTECTED]> writes:
> why do i get a different timezone just because of adding one more century?
> i cannot see an obvious reason.
What version of Postgres and what setting of TZ?
--
Gregory Stark
EnterpriseDB http://www.ent
nd* quite likely corrupt.
Could autovacuum emit log messages as soon as it sees such tables and start
dropping them at some point later?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA services!
--
Sent via pgsql-hackers mailing list (
values were found? If HTSV can hint xmin for a tuple but finds xmax still in
progress perhaps that's a good sign it's not worth dirtying the page?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trained by Bruce Momjian - ask me about EnterpriseDB's Post
ld be simpler to have a wrapper function HTSV() macro which
passes flexible=true to HTSV_internal(). Then vacuum can call HTSV_internal().
I'm not sure what the performance tradeoff is between having an extra argument
to HTSV and having HTSV check a global which messes with optimizations.
re, the optimal size of buckets, etc., it's still
> a severe performance regression bug that should be fixed, IMO.
It was, three months ago:
http://archives.postgresql.org/pgsql-committers/2008-03/msg00129.php
100 is no longer a magic threshold for LIKE queries (in CVS HEAD)
--
Gregor
l currently we use a fixed number of fixed-sized buffers, no? I doubt we'll
change that even if we take this tact of making wal_buffers resizable by
stealing buffers from the buffer manager for precisely the reasons Tom was
describing.
--
Gregory Stark
EnterpriseDB http://www.en
That alone would be worthwhile
even if we bypass all bells and whistles of the buffer manager.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA services!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Perhaps it should just be a single line instead of
two lines both around 20 characters...
Anyways the thing that struck me as odd was the messages appearing *before*
the header. It seems to me the header should print followed by .psqlrc output
followed by normal output.
--
Gregory Stark
Enterpris
at seems like a bad idea to me on performance grounds, but
collation is not a property of the data at all.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's Slony Replication support!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@po
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> It's possible that the second option I described -- teaching Append when to
>> use something other than sum() -- would only work in the cases where
>> constrain
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> The screw case I've seen is when you have a large partitioned table where
>> constraint_exclusion fails to exclude the irrelevant partitions. You're going
>&g
more clever about estimating the number of
rows it produces. Somehow it could be informed of some holistic view of the
quals on its children and how they're inter-dependent. If it's told that only
one of its children will produce rows then it can use max() instead of sum()
to calcula
x27;t that what our most frequent values list does?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's Slony Replication support!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
le size per bucket. Which
allows them to get a more or less accurate estimate for a range covering a
single bucket without changing the size of the bucket.
I'm a bit puzzled which direction you want to go.
> Also, we seem to be getting pretty far away from the original GUC
> discuss
ould just copy from the start to that point and not
bother transferring the rest.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA services!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
"Hakan Kocaman" <[EMAIL PROTECTED]> writes:
> On 6/9/08, Gregory Stark <[EMAIL PROTECTED]> wrote:
>>
>> n_distinct. For that Josh is right, we *would* need a sample size
>> proportional to the whole data set which would practically require us to
>&g
ecause as I said
above and Robert Treat also said, it could be useful to have the constraint in
place for new operations but check it for the existing data at some later
date. (Or even never)
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's
ique for summarizing the results in a nearly constant
sized data structure).
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To ma
list about it being insufficient.
What's needed is some speed benchmarks for complex queries with varying size
statistics so we can see how badly large statistic tables hurt planning time.
The flip side of seeing how much larger tables help planning accuracy is much
harder to measure. Offha
s and the $0.004 you lost or gained in rounding
never comes up again.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's PostGIS support!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
should or
> shouldn't be included remains controversial; consider "default value",
> "per-session/runtime/restart", and "enum lists" as the list of things that are
> most needed there.
Isn't that a list of what's *already* there?
--
G
tool.
Great, I'm glad we've resolved that issue.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's On-Demand Production Tuning
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
parameters
which even if most users can leave them alone those who do use that feature
*do* need to adjust those parameters because the server does *not* get them
right automatically)
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's PostGIS
"Andreas Pflug" <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>> So all you have is our existing file except with an additional layer of
>> quoting to deal with, a useless SET keyword to annoy users, and a file that
>> you need a bison parser
>
> D
"Andreas Pflug" <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>> "Andreas Pflug" <[EMAIL PROTECTED]> writes:
>>
>>> Why do so many people here insist on editing postgresql.conf as primary
>>> means
>>> of changing
include.
The important thing here is to separate files which are "under postgres
control" and those "under user control". That doesn't necessarily mean we have
to ban users from touching the automatically generated config file or switch
formats, but it relieves us of any re
e, instead of emitting them as separate notices.
> Any feelings pro or con about that?
Seems fine either way -- I wonder if one way is more convenient for pgadmin or
applications? I suspect if so it would be the DETAIL field?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
A
or this. But it's another roadblock to
consider akin to "not-really-immutable index expressions" for any proposal
which depends on re-finding index pointers :(
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's Slony Replicati
s fast
as possible.
That said if it happened to latch on to a sync scan herd it would have very
few cache misses which would cause it to rack up very few vacuum cost delay
points. Perhaps the vacuum cost delay for a cache hit ought to be 0?
--
Gregory Stark
EnterpriseDB http://www.
postgresql.conf.sample lately, Tom? It's a disaster.
> Maintenance is already difficult, and becoming more so as we add settings.
What difficulties?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
if this were "nested_loop_cache_hit_rate" for
example, good luck figuring out what to set it to.
The vacuum cost delay factors are probably ripe for such a recast though. I
think we need just one parameter "vacuum_io_bandwidth" or something like that.
The bgwriter parameters mi
re's a whole section on RI
triggers but the closest I see is this, neither of the links appear to refer
to bulk operations:
Optimize referential integrity checks
http://archives.postgresql.org/pgsql-performance/2005-10/msg00458.php
http://archives.postgresql.org/pgsql-hackers/2007-04/msg00
pruning do the second pass of the last vacuum. The trick is to know whether
the last vacuum committed or not. If it didn't commit then it's not safe to
remove those line pointers yet.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> "Tom Lane" <[EMAIL PROTECTED]> writes:
>>> This is expected to take lots of memory because each row-requiring-check
>>> generates an entry in
pending event
trigger list... I wonder how feasible it would be to store the pending trigger
event list in a temporary table instead of in ram.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's On-Demand Production Tuning
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
many "waits for all transactions to finish" we're
accumulating. It seemed safe enough when we had only one but I'm not sure what
the consequences for this action are when there are several of them. Are we
perhaps creating deadlocks?
--
Gregory Stark
EnterpriseD
tuples on the page. or highest
number of unset hint bits seen on the page. or something like that.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's On-Demand Production Tuning
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
xpect 1 (not 0 or 2)
... the other tests you mention which get bitten by midnight
end
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's PostGIS support!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
a table.
I thought the problem had more to do with the former lack of query
invalidation. If someone altered the view we had no way to replan any plans
from a former definition of the view.
Now that we have the query cache would we know that the view had changed and
therefore the wh
ry.
>
> statement_timeout :)
Good point.
Though it occurs to me that if you set FETCH_COUNT in psql (or do the
equivalent in your code ) statement_timeout becomes much less useful.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's
't have already.
The recursive query syntax in the spec actually does include the ability to
assign an output column to show what level of recursive iteration you're on.
So alternately we could have a GUC variable which just allows the DBA to
prohibit any recursive query without such
at concept with the join
plans like merge join or hash join which expect you to be able to be able to
process the records in a specific order?
It sounds like you might have to keep around a stack of started executor nodes
or something but hopefully we can avoid anything like that because, w
d the results. But that's not actually reliable. It's quite possible to
have clauses which will limit the output but not in a way the database can
determine. Consider for example a tree-traversal for a binary tree stored in a
recursive table reference. The DBA might know that th
"David Fetter" <[EMAIL PROTECTED]> writes:
> On Mon, May 19, 2008 at 12:21:20AM -0400, Gregory Stark wrote:
>> "Zoltan Boszormenyi" <[EMAIL PROTECTED]> writes:
>> > Also, it seems there are no infinite recursion detection:
>> >
>>
not result in a report of failure --- and we have seen
> problems with psql crashing at exit, so this isn't an academic point.
It might be a bit weird but pg_regress could stick a message in the output
file before it does the comparison with the expected results.
--
Gregory Stark
Enterp
"your DDL could fail randomly
for reasons that are out of your control" :(
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
when HeapTupleSatisfiesMVCC finds a
tuples which has been moved away by VACUUM FULL... The latter for when it
finds such a tuple but the VACUUM FULL aborted.
It seems quite likely that the compiler is actually right (by chance) and we
shouldn't be optimizing those cases at the expense
ctor of 2 if not quite a bit
more could actually be slowing it down significantly. Using valgrind in
cachegrind mode might also be interesting.
The Linux kernel does have some macros meant to mark unlikely branches
(usually assertion failures) but I'm not sure how they work. And Gcc als
"Suresh" <[EMAIL PROTECTED]> writes:
> Hello,
>
> I have custom postgres code.
What kind of code is this? The error below is typical if you create new
threads in the server.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about Ent
an 8.1.11 btw. Updating your binaries should be a 5 minute job
and there are real bugs fixed in those releases.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL
training!
--
Sent via pgsql-hacke
g run 3% slower instead of
using that 3% i/o bandwidth headroom to run vacuum outside the critical path.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL
training!
--
Sent via pgsql-hackers mailing list (
default to current implicit behavior of col_pkey.
This is all so that the primary key shows up with a nice "PRIMARY KEY" instead
of just the unique index?
The "PREBUILT" seems unnecessary in that syntax.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.
t to:
Andrew Dunstan <[EMAIL PROTECTED]>,PostgreSQL-development
do precisely the opposite of what you would want?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA services!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
"Zdenek Kotala" <[EMAIL PROTECTED]> writes:
> Gregory Stark napsal(a):
>> "Josh Berkus" <[EMAIL PROTECTED]> writes:
>>
>>> How about hacking together a simple patch tracker instead, as Bruce
>>> suggested? I've never found
ly really makes sense if you're spending
a lot more time executing than planning queries. Either that means you're
preparing queries once and then executing them many many times or you're
planning much slower queries where planning time is insignificant compared to
the time to exe
file on the web server.
If you have a clever IMAP server and a clever IMAP client you're actually not
far from that world today. But a lot of us are stuck with at least one
unclever piece of software there.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trai
t would be to make a perl script which automatically
uploads any attachments sent to -hackers to the wiki.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL
training!
--
Sent via pgsql-hacke
large patches up on the wiki in cases like that now,
but isn't there a size limit on the wiki too?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL
training!
--
Sent via pgsql-hackers mailing list (p
irected to something like "more" or "head" or whatever with the result
*still* showing up on the screen.
It's one thing to change the default behaviour. It's another to disregard
user-requested options.
--
Gregory Stark
EnterpriseDB http://www.enterpris
You will tie
yourselves in knots if you try to enumerate all the types of terminals, places
people redirect output, and uses people might make for the output. And it will
result in very complex, hard to explain behaviour which will surprise and
disappoint users.
--
Gregory Stark
EnterpriseDB
s that consistent?
What are you talking about? "screen output"?
Are you even getting my emails? Please confirm that you receive this email.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's On-Demand Production Tuning
--
Sent vi
cParams() !!!) then people will
switch to other things.
c.f.
http://www.areino.com/hackeando/
(there is a semicolon here but that's a microsoft-ism, postgres would actually
be more affected by this style of attack without the semicolon)
--
Gregory Stark
EnterpriseDB http
s volume of log activity
> would be too much. Just because someone with classified clearance is looking
> at a big table that also has a lot of secret info in it, not all installs will
> want a million errors reported just because there's data that person can't see
> ava
>> Greg
>> Stark's arguments), then it should have priority over ioctl(), not the other
>> way around.
>
> OK, two people like it, no one has objected. :-) I will work on making
> those changes. Thanks.
Uh, precisely what changes are you referring to now? "
ing rules in client
>> libraries, would quite possibly be enough.)
>
> MySQL did this already.
Did you guys miss Tom's comment up-thread? Postgres already does this if you
use PQExecParams().
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about
h time it's actually clearer to include
them directly in the query.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's On-Demand Production Tuning
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
als. That's
just too big of a usability hit and as you pointed out with the common use
case of dynamically choosing ORDER BY it doesn't even catch other common
cases. You need to step back and find a way to prevent user input from ending
up in the query regardless of whether it'
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>>
>> > We do look at COLUMNS if the ioctl() fails, but not for file/pipe
>> > output.
>>
>>
formatted to
72 columns.
But your point is valid, that's why I'm not too worried about cases where
COLUMNS is set to the desired width but readline interferes with it. In those
cases we would be using the ioctl value anyways. It would probably still be a
good idea to getenv(COLUMNS)
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>> > Now, we could get fancy and honor $COLUMNS only in non-interactive mode,
>> > but that seems confusing.
>>
>> We could always read COLUMNS early on before readline is initiali
401 - 500 of 1651 matches
Mail list logo
