anyone else feel inclined to fix this?
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Tom Lane wrote:
It is now fixed in the attached patch.
Applied with some additional cleanup (the code wasn't multibyte-aware,
and so could get fooled in some Far Eastern encodings).
I am very pleased to hear. This was my first patch submitted. :-)
Best Regards,
Michael Paesold
Tom Lane wrote:
It is now fixed in the attached patch.
Applied with some additional cleanup (the code wasn't multibyte-aware,
and so could get fooled in some Far Eastern encodings).
Looking at your cleanup is a good for learning more about C. :-)
But I have one another question, you
, or should pg_strcasecmp be used here?
Best Regards,
Michael Paesold
psql-autocommit.diff
Description: Binary data
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
I wrote:
Patch attached. Is strcasecmp ok, or should pg_strcasecmp be used here?
I don't know how I did it, but this was the wrong patch. Correct patch
attached now.
Best Regards,
MIchael Paesold
variables.c.diff
Description: Binary data
---(end of broadcast
to oracle, mssql etc. At least at the
interactive level, the patch would give them the option to have their
accustomed way of handling e.g. typos.
Thank you for your time and thank you for any response!
Best Regards,
Michael Paesold
P.S. attached is a version of the patch with more/better comments
Alvaro Herrera wrote:
On Tue, Sep 21, 2004 at 02:30:17PM +0200, Michael Paesold wrote:
http://archives.postgresql.org/pgsql-hackers/2004-09/msg00576.php
One potential problem I see with the patch is that it opens lots of
savepoints but does not release any. In this mode, given autocommit
Michael Paesold [EMAIL PROTECTED] writes:
Alvaro Herrera wrote:
One potential problem I see with the patch is that it opens lots of
savepoints but does not release any.
Well, given that EXCEPTION blocks in Pl/pgSQL and the like also never
release savepoints
That statement is flat
not using it, would it?
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
, but replaying the logs from the whole
benchmark session)
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
ITAGAKI Takahiro wrote:
I think that there is room for improvement in WAL.
Here is a patch for it.
I think you should resend your patch as a context diff (diff -c). Otherwise
it's hard to see what your patch does.
Best Regards,
Michael Paesold
---(end of broadcast
Neil Conway wrote:
On Tue, 2005-01-25 at 16:49 -0700, Ed L. wrote:
The attached dbsize patch:
+ makes relation_size(relname) include toast tables;
+ adds aggregate_relation_size(relname) to count table data and indices;
+ adds indices_size(relname) to report the size of indices for a
relation;
the server
and query that before every release.
What do you think?
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Greg Sabino Mullane wrote:
Michael Paesold wrote:
2) Implement a server-side function to get the savepoints from the server
and query that before every release.
I could not find a way to do this. Is there any interface to the list?
Alvaro suggested to implement such a function. It is not there yet
\reseterror in .psqlrc. I
previously suggested an AUTO setting (additional to ON/OFF) that disables
\reseterror when reading from a non-tty. So putting \reseterror AUTO in
.psqlrc would be save.
Otherwise, I could not find a way to break it. :-)
Best Regards,
Michael Paesold
at the moment. I still think there is a better
way (parsing statements like it's already done for
no-transaction-allowed-statements), but hey, as soon as your patch will be
applied, I can myself propose another patch to improve this. ;-)
Best Regards,
Michael Paesold
---(end
Bruce Momjian wrote:
Michael Paesold wrote:
Some suggestions in random order:
* I think you should use PSQLexec instead of using PQexec directly.
PSQLexec
is used by all \-commands and prints out queries with -E, which is very
helpful for debugging.
-E display queries that internal
off in my .psqlrc file, too, and I know I am not the only one)
* another one that will also work in scripts
I hope you understand and accept the issue here.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 1: subscribe and unsubscribe
Richard Huxton wrote:
Michael Paesold wrote:
But people (like me for example) will want to enable this behaviour by
default. So they (me too) will put the option in .psqlrc. It is then
enabled by default. But then many of my scripts will destroy data
instead of just erroring out.
I just don't
that's outside any
spec anyway, but I do think we ought to think twice about adding this
to SQL literal handling.
+1 from me on this for Tom -- please don't break spec compliance!
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 7: don't
to pg_dump
is certainly easier)
You forgot to document the long option, I think.
Are the man pages generated from the sgml docs? Have never had a look at
that.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 3: if posting/reading through
it's not too far off.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
the former.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
it turns cost-based vacuum delay on or off. I
believe not many will have vacuum_cost_delay enabled in postgresql.conf, but
will want to enable it for autovacuum.
At least I do.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 3: Have
for our and many
other production databases. I suggest that should be a plain VACUUM.
Otherwise I think you have done great job finally integrating auto vacuum
into the backend.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 1
.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
tests for AUTOCOMMIT and
ON_ERROR_ROLLBACK and possibly others. There are currently no regression
tests specifically for psql features, but since the regression tests are
executed via psql, there would be no problem in creating a set of such
tests, right?. I could write some.
Best Regards,
Michael
. The missing dependencies for sequences
were a bug in the first place, IMHO.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
://cnswww.cns.cwru.edu/~chet/readline/rltop.html
IMHO libreadline does not sound good.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your
wants to step up to maintain
such a list, not as detailed as the release notes probably.
Just my two (Euro)cents.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http
of DROP TRIGGER.
Thanks again.
Best Regards,
Michael Paesold
---(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
.
Best Regards,
Michael Paesold
For quick reference:
http://momjian.us/main/writings/pgsql/sgml/sql-createconstraint.html
Index: create_constraint.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/ref/create_constraint.sgml,v
Regards
Michael Paesold
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
problem,
perhaps because we round to very few digits, but well.
Please apply this patch. I can accept the performance drop, as long as
there won't be bad surprises with correctness.
Best Regards
Michael Paesold
---(end of broadcast)---
TIP 1
is
really unsafe?
We usually *round* all values to at maximum 4 decimal places -- are we
on the save side? Does this only affect high precision division, or any
divisions?
Best Regards
Michael Paesold
Bruce Momjian wrote:
Because this has not been applied, this has been saved for the 8.4
about *why* the recommendation was
changed. We have one rule-based setup here, and it has been working
flawlessly for us,... so personally I don't even know the reasons.
Best Regards
Michael Paesold
---(end of broadcast)---
TIP 1: if posting/reading
Joshua D. Drake wrote:
Michael Paesold wrote:
I would also add another sentence about *why* the recommendation was
changed. We have one rule-based setup here, and it has been working
flawlessly for us,... so personally I don't even know the reasons.
Rules are extremely slow in comparisons
37 matches
Mail list logo
