Bruce Momjian br...@momjian.us wrote:
Itagaki Takahiro wrote:
When psql opens a file with -f or \i, it checks first 3 bytes of the
file. If they are BOM, discard the 3 bytes and change client encoding
to UTF8 automatically.
Seems there is community support for accepting BOM:
Bruce Momjian wrote:
1. Invent a GUC that has the settings backwards-compatible,
oracle-compatible, throw-error (exact spellings TBD). Factory default,
at least for a few releases, will be throw-error. Make it SUSET so that
unprivileged users can't break things by twiddling it; but it's
2009/10/20 Bruce Momjian br...@momjian.us:
Robert Haas wrote:
I do agree with Peter's concerns about limiting the character set of the
name string, and maybe there should be some sort of length limit too.
I don't have a strong feeling about this. If limiting this to 7-bit
characters
Aidan Van Dyk wrote:
* Tom Lane t...@sss.pgh.pa.us [091019 18:45]:
Actually, I think any attempt to do that would result in a fork,
and a consequent splintering of the community. We can get away
with occasionally cleaning up individual problematic behaviors
(example: implicit casts to text),
2009/10/19 Tom Lane t...@sss.pgh.pa.us:
I wrote:
A server-side plugin can provide a guarantee that there are no bad
passwords (for some value of bad, and with some possible adverse
consequences). We don't have that today.
BTW, it strikes me that ALTER USER RENAME introduces an interesting
Simon Riggs wrote:
On Fri, 2009-10-16 at 09:33 +0300, Heikki Linnakangas wrote:
If you pause recovery, and then continue, we reset to target none
mode, even if a stopping point was set previously.
Yes, currently. Resetting the target mode will do what you want, rather
than continue.
On Mon, Oct 19, 2009 at 9:34 PM, Magnus Hagander mag...@hagander.net wrote:
2009/10/19 Dave Page dp...@pgadmin.org:
On Mon, Oct 19, 2009 at 3:42 PM, Massa, Harald Armin c...@ghum.de wrote:
Would'nt this also make sense for PostgreSQL? That is, when no environment
is set, and no SET-command is
2009/10/20 Dave Page dp...@pgadmin.org:
On Mon, Oct 19, 2009 at 9:34 PM, Magnus Hagander mag...@hagander.net wrote:
2009/10/19 Dave Page dp...@pgadmin.org:
On Mon, Oct 19, 2009 at 3:42 PM, Massa, Harald Armin c...@ghum.de wrote:
Would'nt this also make sense for PostgreSQL? That is, when no
On Tue, Oct 20, 2009 at 1:21 AM, Tom Lane t...@sss.pgh.pa.us wrote:
If the parameter is defined as the chance that a page is in cache
there is very real physical meaning to it.
We have no such parameter...
What a simple person like me would think would work is:
- call the parameter
On Tue, 2009-10-20 at 10:33 +0300, Heikki Linnakangas wrote:
At this point, I'd like to cut out all those control functions to
pause/stop at various points from the patch.
OK
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
On Tue, 2009-10-20 at 09:43 +0100, Simon Riggs wrote:
On Tue, 2009-10-20 at 10:33 +0300, Heikki Linnakangas wrote:
At this point, I'd like to cut out all those control functions to
pause/stop at various points from the patch.
OK
Maybe OK, I should say. Some parts are important for testing
We can hook SELECT, INSERT, UPDATE and DELETE with ExecutorXxx_hooks,
but there is no way to hook DDL commands. Can I submit a patch to add
ProcessUtility_hook?
pg_stat_statements module also handle DDL commands as same as normal
queries. Fortunately, autovacuum calls call vacuum() directly,
so
On Tue, 2009-10-20 at 14:41 +0900, Itagaki Takahiro wrote:
UTF8 encoding text files with BOM (Byte Order Mark) are commonly
used in Windows, though BOM was designed for UTF16 text originally.
However, psql cannot read such format even if we set client encoding
to UTF8. Is it worth supporting
Itagaki Takahiro escreveu:
We can hook SELECT, INSERT, UPDATE and DELETE with ExecutorXxx_hooks,
but there is no way to hook DDL commands. Can I submit a patch to add
ProcessUtility_hook?
+1. Hey, I was thinking about that yesterday. ;)
pg_stat_statements module also handle DDL commands as
On Tue, Oct 13, 2009 at 4:11 PM, Andrew Dunstan and...@dunslane.net wrote:
On the second question, obviously the user can call SET to set a
value, as I've done for now in psql, however in other DBMSs, it may be
set in the connection string. My feeling would be to do that, and
possibly add
Magnus Hagander mag...@hagander.net writes:
2009/10/19 Tom Lane t...@sss.pgh.pa.us:
Now we have a user with name equal to password, which no sane security
policy will think is a good thing, but the plugin had no chance to
prevent it.
The big difference is that you need to be superuser to
Greg Smith gsm...@gregsmith.com wrote:
The unfortunate reality of accounts receivable is that reports run
to list people who owe one money happen much more often than posting
payments into the system does.
How often do you have to print a list of past due accounts? I've
generally seen that
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Tom Lane replied to Ron Mayer:
Would postgres get considerably cleaner if a hypothetical 9.0 release
skipped backward compatibility and removed anything that's only
On Tue, Oct 20, 2009 at 9:42 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
2009/10/19 Tom Lane t...@sss.pgh.pa.us:
Now we have a user with name equal to password, which no sane security
policy will think is a good thing, but the plugin had no chance to
On Tue, Oct 20, 2009 at 10:07 AM, Greg Sabino Mullane g...@turnstep.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Tom Lane replied to Ron Mayer:
Would postgres get considerably cleaner if a hypothetical 9.0 release
skipped backward compatibility and removed anything that's
Greg Sabino Mullane g...@turnstep.com writes:
I'm sure the casting changes broke more applications and prevented more
people from upgrading than every thing on Ron's list for a clean 9.0 would.
Not that I'm necessarily promoting his idea, but 8.3 was already a
all-at-once breakage release.
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
1. Invent a GUC that has the settings backwards-compatible,
oracle-compatible, throw-error (exact spellings TBD). Factory default,
at least for a few releases, will be throw-error. Make it SUSET so that
unprivileged users can't break
Bruce Momjian br...@momjian.us writes:
Seems there is community support for accepting BOM:
http://archives.postgresql.org/pgsql-hackers/2009-09/msg01625.php
That discussion has approximately nothing to do with the
much-more-invasive change that Itagaki-san is suggesting.
In particular I
Magnus Hagander mag...@hagander.net writes:
2009/10/20 Dave Page dp...@pgadmin.org:
Yeah, and there's a similar API on *BSD I believe, but nothing standard.
Right, but it might be worth investigating using the API that's
available on the platform, if one is. It's a fairly simple operation
Robert Haas wrote:
I think the real issue, though, is that answer
to Ron's original question is No. When backward compatibility gets
in the way of cool new features, that's worth considering. But
removing backward compatibility just for the sake of removing backward
compatibility doesn't
Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
2009/10/20 Dave Page dp...@pgadmin.org:
Yeah, and there's a similar API on *BSD I believe, but nothing standard.
Right, but it might be worth investigating using the API that's
available on the platform, if one is. It's a fairly
Greg Sabino Mullane g...@turnstep.com writes:
That particular example is a very poor one for illustrating your
point. You severely underestimate get away with for the implicit
cast changes in 8.3. This was a really big deal for many, many users
of Postgres, and continues to cause many problems
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Seems there is community support for accepting BOM:
http://archives.postgresql.org/pgsql-hackers/2009-09/msg01625.php
That discussion has approximately nothing to do with the
much-more-invasive change that Itagaki-san is
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Tom Lane wrote:
It would be a seriously bad idea for this to behave one way on some
platforms and differently on others.
Why would that be so bad? On platforms that support getting argv[0],
you'd get mycoolapp in the application
On Tue, Oct 20, 2009 at 10:46:10AM -0400, Andrew Dunstan wrote:
Robert Haas wrote:
I think the real issue, though, is that answer to Ron's original
question is No. When backward compatibility gets in the way of
cool new features, that's worth considering. But removing backward
compatibility
Andrew Dunstan and...@dunslane.net writes:
What I think we might sensibly do is to eat the leading BOM of an SQL
file iff the client encoding is UTF8, and otherwise treat it as just
bytes in whatever the encoding is.
That seems relatively non-risky.
Should we also do the same for files
On Tue, Oct 20, 2009 at 10:32 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
1. Invent a GUC that has the settings backwards-compatible,
oracle-compatible, throw-error (exact spellings TBD). Factory default,
at least for a few releases, will be
Andrew Dunstan and...@dunslane.net wrote:
What I think we might sensibly do is to eat the leading BOM of an
SQL file iff the client encoding is UTF8, and otherwise treat it as
just bytes in whatever the encoding is.
Only at the beginning of the file or stream? What happens when people
2009/10/20 Tom Lane t...@sss.pgh.pa.us:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Tom Lane wrote:
It would be a seriously bad idea for this to behave one way on some
platforms and differently on others.
Why would that be so bad? On platforms that support getting argv[0],
2009/10/20 Tom Lane t...@sss.pgh.pa.us:
Andrew Dunstan and...@dunslane.net writes:
What I think we might sensibly do is to eat the leading BOM of an SQL
file iff the client encoding is UTF8, and otherwise treat it as just
bytes in whatever the encoding is.
That seems relatively non-risky.
On Tue, 20 Oct 2009, Kevin Grittner wrote:
How often do you have to print a list of past due accounts? I've
generally seen that done weekly or monthly, in the same places that
there are many people standing full time in payment windows just to
collect money from those lining up to pay.
This
Merlin Moncure mmonc...@gmail.com writes:
How about warning for release before making the big switch? The text
cast change, while ultimately good, maybe could have been stretched
out for a release or two...it was painful. I do though absolutely
think that it was good in the end to not
On Tue, Oct 20, 2009 at 11:48 AM, David Fetter da...@fetter.org wrote:
On Tue, Oct 20, 2009 at 10:46:10AM -0400, Andrew Dunstan wrote:
Robert Haas wrote:
I think the real issue, though, is that answer to Ron's original
question is No. When backward compatibility gets in the way of
cool new
Tom Lane t...@sss.pgh.pa.us wrote:
if your software is written to depend on the appname being set a
particular way
then you're not using for its intended purpose, I should think. Since
any client can set this to whatever they want, having the application
name as a default, rather than NULL
2009/10/20 Tom Lane t...@sss.pgh.pa.us:
Merlin Moncure mmonc...@gmail.com writes:
How about warning for release before making the big switch? The text
cast change, while ultimately good, maybe could have been stretched
out for a release or two...it was painful. I do though absolutely
think
Magnus Hagander mag...@hagander.net writes:
Also, how many platforms can't we do this on? If we have BSD and
Windows covered already. on linux, I believe you can easily read it
out of /proc/self/cmdline, no?
Writing a pile of platform-specific code for this is simply insane from
a support
On Oct 20, 2009, at 10:51 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
What I think we might sensibly do is to eat the leading BOM of an SQL
file iff the client encoding is UTF8, and otherwise treat it as just
bytes in whatever the encoding is.
That seems relatively
2009/10/20 Tom Lane t...@sss.pgh.pa.us:
Magnus Hagander mag...@hagander.net writes:
Also, how many platforms can't we do this on? If we have BSD and
Windows covered already. on linux, I believe you can easily read it
out of /proc/self/cmdline, no?
Writing a pile of platform-specific code for
OpenACS uses three compatibility settings in its recommended config, two
of which it has been proposed to remove.
I have been investigating all three.
1. default_with_oids= true
While it's not proposed to remove this option, its use seems
quite unnecessary in OpenACS.
David Fetter da...@fetter.org writes:
This isn't about a passion for neatness. It's about recognizing
that some experiments have failed and weeding out the failures. The
RULE system, for example, was a ground-breaking innovation in the
sense of being a truly new idea. Evidence over the
Pavel Stehule wrote:
2009/10/20 Tom Lane t...@sss.pgh.pa.us:
Merlin Moncure mmonc...@gmail.com writes:
How about warning for release before making the big switch? ?The text
cast change, while ultimately good, maybe could have been stretched
out for a release or two...it was painful. ?I do
Folks,
I'd like to see about removing the following GUCs:
add_missing_from (should be off)
array_nulls (should be on)
commit_delay (no need for this knob)
commit_siblings (no need for this knob)
default_with_oids (should be off)
password_encryption (should be on)
regex_flavor (should be
Zdenek Kotala wrote:
Andrew Chernow píše v po 19. 10. 2009 v 14:14 -0400:
# ./pg_ctl
ld.so.1: pg_ctl: fatal: relocation error: R_AMD64_32: file
/usr/local/postgres64/lib/libpq.so.5: symbol (unknown): value
0xfd7fff1cf210 does not fit
Killed
{snip}
David Fetter da...@fetter.org wrote:
I'd like to see about removing the following GUCs:
sql_inheritance (should be on)
I'd rather see that stay, so that I can make sure it's off. That
said, we have other ways to enforce shop policy on this, if need be.
track_counts (should be on)
I
On Tue, 2009-10-20 at 10:49 -0700, David Fetter wrote:
synchronize_seqscans (should be on)
Right now this is used for pg_dump, because pg_dump could un-cluster a
previously clustered table (I believe Greg Stark made this observation).
This is actually a stats/planner issue more than anything
u235sentinel píše v út 20. 10. 2009 v 12:22 -0600:
Now I'm running and will add a few more things in like readline. The
goal is to build plr and plperl and load them into postgres.
Hmm, I'm afraid that 64bit plperl is a problem. Solaris 10 is not
shipped with 64bit perl :(.
Zdenek
David Fetter da...@fetter.org writes:
I'd like to see about removing the following GUCs:
add_missing_from (should be off)
array_nulls (should be on)
commit_delay (no need for this knob)
commit_siblings (no need for this knob)
default_with_oids (should be off)
password_encryption (should be
Jeff Davis pg...@j-davis.com writes:
On Tue, 2009-10-20 at 10:49 -0700, David Fetter wrote:
synchronize_seqscans (should be on)
Right now this is used for pg_dump, because pg_dump could un-cluster a
previously clustered table (I believe Greg Stark made this observation).
In general, the
--On 20. Oktober 2009 10:49:33 -0700 David Fetter da...@fetter.org wrote:
track_activities (should be on)
track_counts (should be on)
update_process_title (should be on)
Removing all track* GUCs would only make sense if we are going to make
autovacuum mandatory, i think. And i thought
In response to Bernd Helmle maili...@oopsware.de:
--On 20. Oktober 2009 10:49:33 -0700 David Fetter da...@fetter.org wrote:
track_activities (should be on)
track_counts (should be on)
update_process_title (should be on)
I'm not replying in the correct part of the thread, but I just
Tom,
Emmanuel Cecchet m...@asterdata.com writes:
Tom Lane wrote:
There aren't any. You can *not* put a try/catch around arbitrary code
without a subtransaction. Don't even think about it
Well then why the tests provided with the patch are working?
Because they carefully
David Fetter wrote:
Folks,
I'd like to see about removing the following GUCs:
add_missing_from (should be off)
array_nulls (should be on)
commit_delay (no need for this knob)
commit_siblings (no need for this knob)
default_with_oids (should be off)
password_encryption (should be on)
Emmanuel Cecchet m...@asterdata.com writes:
Tom Lane wrote:
The key word in my sentence above is arbitrary. You don't know what
a datatype input function might try to do, let alone triggers or other
functions that COPY might have to invoke. They might do things that
need to be cleaned up
I don't thing, so drop some implicit-casts was huge problem. Somebody
could to use Peter's patch, that recreate missing casts.
True, but we should have had those compatibility pathes (Peter's patch)
ready before we released, and advertised them in the release notes.
sure
Maybe we have to
Dave Page dp...@pgadmin.org writes:
I just realised there's a nasty problem with this. In my client
application, I can use PQconninfoParse to determine if
application_name (or fallback_application_name) are valid connection
string options for the version of libpq that I have.
However, there
On Sat, 2009-10-03 at 09:45 +0300, I wrote:
So let's get rid of that. Selecting (or in general, operating) on a
table with children only checks the privileges on that table, not the
children.
If I'm seeing this right, it's literally a one-line fix. Patch attached
with documentation and test
On Wed, 2009-08-19 at 19:11 +0200, Stefan Kaltenbrunner wrote:
correct - svr1 has bison 1.875 and flex 2.5.35 (for the -HEAD builds)
and flex 2.5.4 for the back branches.
Where? In which directories?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
Peter Eisentraut pete...@gmx.net writes:
If I'm seeing this right, it's literally a one-line fix.
At least a two-line fix, please: that needs a comment. But yeah,
I think that's basically all that would have to change.
regards, tom lane
--
Sent via pgsql-hackers
Magnus Hagander mag...@hagander.net writes:
2009/10/20 Tom Lane t...@sss.pgh.pa.us:
psql or java. The cases that are actually useful are the ones where
the application sets it. I don't think we should have a default at all
--- you don't set it, you don't get a name.
For psql, yes.
What
I have a a postgres database implementation that needs to be enhanced to
meet PCI compliance for encrypting sensitive data inside the database.
I'm looking at dm-crypt to encrypt my filesystems to prevent against
theft of hardware, but we also have a requirement to encrypt a few
important
http://developer.postgresql.org/pgdocs/postgres/release-8-5.html
If they're OK, I can bundle it tomorrow.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Oct 20, 2009 at 12:16:42PM -0400, Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
Also, how many platforms can't we do this on? If we have BSD and
Windows covered already. on linux, I believe you can easily read it
out of /proc/self/cmdline, no?
Writing a pile of
On Fri, Oct 02, 2009 at 07:57:13PM -0700, daveg wrote:
On Fri, Oct 02, 2009 at 10:41:07AM -0400, Alvaro Herrera wrote:
daveg escribió:
I work with Kunal and have been looking into this. It appears to be the
same
as the bug described in:
daveg da...@sonic.net writes:
I'd like a default, especially for psql, to help identify interactive
sessions.
psql can certainly provide a default, and maybe even do something
actually useful like report the -f file it's running. The question here
is whether it is worth the trouble for libpq
daveg da...@sonic.net writes:
We have had this deployed in our test and production environments for a
couple weeks now. We have not seen any further instance of the problem.
Without the patch, we would have expected to see at least a few by now.
So the patch appears to be effective.
Cool,
On 10/20/09 2:11 PM, Peter Eisentraut wrote:
http://developer.postgresql.org/pgdocs/postgres/release-8-5.html
If they're OK, I can bundle it tomorrow.
I'd like to edit these. Where's source?
--Josh Berkus
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
Why? Are they causing problems leaving them there? What sorts of
problems will arise by *removing* them? I know with OACS,
add_missing_from is required right now, but that code *should* be fixable,
and there is an overwhelming reason from an advancement perspective to
having it removed
On Tue, 20 Oct 2009, Bernd Helmle wrote:
--On 20. Oktober 2009 10:49:33 -0700 David Fetter da...@fetter.org wrote:
track_activities (should be on)
track_counts (should be on)
update_process_title (should be on)
Removing all track* GUCs would only make sense if we are going to make
Josh Berkus j...@agliodbs.com writes:
I'd like to edit these. Where's source?
In CVS ...
http://archives.postgresql.org/pgsql-committers/2009-10/msg00090.php
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Magnus Hagander mag...@hagander.net wrote:
For java, it doesn't even go through libpq, so it wouldn't be set
for it. And I'd expect the JDBC driver to set it based on Something
Reasonable (TM) that it can get the information about. After all,
this thing was listed in the JDBC spec somebody
David Fetter da...@fetter.org writes:
add_missing_from (should be off)
regex_flavor (should be advanced, regex flavor can be controlled on a
per-regex basis when they're advanced)
I believe that we do have consensus on removing those two, based on
discussions here and here respectively:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Magnus Hagander mag...@hagander.net wrote:
For java, it doesn't even go through libpq, so it wouldn't be set
for it. And I'd expect the JDBC driver to set it based on Something
Reasonable (TM) that it can get the information about. After all,
On 10/20/09 3:06 PM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
I'd like to edit these. Where's source?
Actually, change this to I *need* to edit it. There's several errors.
Working on it now, but can't promise to finish by tommorrow AM.
--Josh Berkus
--
Sent via pgsql-hackers
Meanwhile, last chance for anyone to object to killing these two?
Nope. People will have to fix their apps, but it's about time. I'll
try to remember to advertise the breakage ...
--Josh Berkus
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Peter Eisentraut wrote:
On Wed, 2009-08-19 at 19:11 +0200, Stefan Kaltenbrunner wrote:
correct - svr1 has bison 1.875 and flex 2.5.35 (for the -HEAD builds)
and flex 2.5.4 for the back branches.
Where? In which directories?
/usr/bin/flex is 2.5.4 and /usr/local/bin/flex is 2.5.35.
Stefan
Josh Berkus j...@agliodbs.com writes:
Meanwhile, last chance for anyone to object to killing these two?
Nope. People will have to fix their apps, but it's about time. I'll
try to remember to advertise the breakage ...
Hmm, did you want to try to include these changes in alpha2? I wasn't
On 10/20/09 5:06 PM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
Meanwhile, last chance for anyone to object to killing these two?
Nope. People will have to fix their apps, but it's about time. I'll
try to remember to advertise the breakage ...
Hmm, did you want to try to
Actually, change this to I *need* to edit it. There's several errors.
Working on it now, but can't promise to finish by tommorrow AM.
Done, actually. Apologies for tab spacing; I can't seem to get this to
work right in emacs-sgml. So I've attached the file instead of a patch.
I edited
On Tue, Oct 20, 2009 at 1:49 PM, David Fetter da...@fetter.org wrote:
Folks,
I'd like to see about removing the following GUCs:
add_missing_from (should be off)
array_nulls (should be on)
commit_delay (no need for this knob)
commit_siblings (no need for this knob)
default_with_oids
Rod Taylor rod.tay...@gmail.com writes:
I tried making a functional index based on an expression containing
the 2 argument regexp_matches() function. Is there a reason why this
function is not marked immutable instead of normal?
So I went to see about making the changes to remove regex_flavor,
Robert Haas robertmh...@gmail.com wrote:
We just had a conversation about whether or not to massively break
backward compatibility. The consensus was, as I'm sure you are aware,
was no.
We should not discuss serveral kinds of parameters at once.
1. Options for backward compatibility with
Here is a patch to add ProcessUtility_hook to handle all DDL
commands in user modules. (ProcessUtility_hook_20091021.patch)
It adds a global variable 'ProcessUtility_hook' and
export the original function as 'standard_ProcessUtility'.
Euler Taveira de Oliveira eu...@timbira.com wrote:
Zdenek Kotala wrote:
Hmm, I'm afraid that 64bit plperl is a problem. Solaris 10 is not
shipped with 64bit perl :(.
Zdenek
Found that the hard way today :-)
I'm downloading perl source and will make a 64 bit version. Anybody
know if -m64 will work with compiling 64 bit perl?
I'll hack the makefile and give it a shot.
No need to hack it, set CFLAGS during configure:
shell]# CFLAGS=-m64 ./configure (options)
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
On Wed, 21 Oct 2009, Itagaki Takahiro wrote:
In addition, it might be good idea to hide some parameters from the
default postgresql.conf in order to simplify it, even though we will
still have those knobs.
That might be an idea for anything that is meant to be 'deprecated' in the
first
David Christensen da...@endpoint.com wrote:
Is that only when the default client encoding is set to UTF8
(PGCLIENTENCODING, whatever), or will it be coded to work with the
following:
$ psql -f file
Where file is:
BOM
SET CLIENT ENCODING 'utf8';
Sure. Client encoding is declared in
Marc G. Fournier scra...@hub.org wrote:
In addition, it might be good idea to hide some parameters from the
default postgresql.conf in order to simplify it, even though we will
still have those knobs.
That might be an idea for anything that is meant to be 'deprecated' in the
first
On Tue, 20 Oct 2009, David Fetter wrote:
commit_delay (no need for this knob)
commit_siblings (no need for this knob)
Both these knobs do something that's valuable sometimes: help group
commits into bigger chunks when there are lots of active clients. I've
watched it help a bit on heavy
93 matches
Mail list logo
