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 wr
"Marc G. Fournier" 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 place,
David Christensen 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
> Where is:
>
> SET CLIENT ENCODING 'utf8';
Sure. Client encoding is declared in body of a file, but BO
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 place
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
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?
:
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 wrote:
> > pg_stat_statements modu
Robert Haas 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 old PostgreSQL
Rod Taylor 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, and
was astonishe
On Tue, Oct 20, 2009 at 1:49 PM, 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
> 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 sev
On 10/20/09 5:06 PM, Tom Lane wrote:
> Josh Berkus 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 the
Josh Berkus 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
intending to be
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
> 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 su
On 10/20/09 3:06 PM, Tom Lane wrote:
> Josh Berkus 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 mailing list (pgs
"Kevin Grittner" writes:
> Magnus Hagander 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 s
David Fetter 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:
http://archives.pos
Magnus Hagander 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 said...
I can't
Josh Berkus 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 subscription:
ht
On Tue, 20 Oct 2009, Bernd Helmle wrote:
--On 20. Oktober 2009 10:49:33 -0700 David Fetter 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
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 (ie
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 chang
daveg 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, thanks for the
daveg 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 to try to repo
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:
> > >
> > > http://archives.p
On Tue, Oct 20, 2009 at 12:16:42PM -0400, Tom Lane wrote:
> Magnus Hagander 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-specif
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
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 fie
Magnus Hagander writes:
> 2009/10/20 Tom Lane :
>> "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 about having psql -f foo.sq
Peter Eisentraut 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 mailing list (pgsql-
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
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 te
Dave Page 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 is no way tha
>>
>> 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 h
Emmanuel Cecchet 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 after, and
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)
regex_fla
Tom,
Emmanuel Cecchet 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 exercise only a tiny frac
In response to Bernd Helmle :
>
>
> --On 20. Oktober 2009 10:49:33 -0700 David Fetter 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 happened
to notice this by a
--On 20. Oktober 2009 10:49:33 -0700 David Fetter 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 update_process_title
Jeff Davis 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 setting results i
David Fetter 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 on)
> reg
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
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 els
David Fetter 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 believe we foun
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}
/usr/local/postgres64/lib/libp
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 advanced,
Pavel Stehule wrote:
> 2009/10/20 Tom Lane :
> > Merlin Moncure 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
> >> t
David Fetter 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 decades since h
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.
2009/10/20 Tom Lane :
> Magnus Hagander 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
>
On Oct 20, 2009, at 10:51 AM, Tom Lane wrote:
Andrew Dunstan 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.
Is that only
Magnus Hagander 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 point of view. The f
2009/10/20 Tom Lane :
> Merlin Moncure 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
Tom Lane 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 (at least for cli
On Tue, Oct 20, 2009 at 11:48 AM, David Fetter 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 feat
Merlin Moncure 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 support a compatibili
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 i
2009/10/20 Tom Lane :
> Andrew Dunstan 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.
+1.
>> Should we also do the
2009/10/20 Tom Lane :
> Heikki Linnakangas 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 applicati
Andrew Dunstan 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
concatenate files? W
On Tue, Oct 20, 2009 at 10:32 AM, Tom Lane wrote:
> Bruce Momjian 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 S
Andrew Dunstan 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 passed via \copy? W
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
>> com
Heikki Linnakangas 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 name by default. On others,
Tom Lane wrote:
Bruce Momjian 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
"Greg Sabino Mullane" 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 to this d
Tom Lane wrote:
> Magnus Hagander writes:
>> 2009/10/20 Dave Page :
>>> 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
>> after al
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 r
Magnus Hagander writes:
> 2009/10/20 Dave Page :
>> 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
> after all, so it won't take huge
Bruce Momjian 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 think an automa
Bruce Momjian 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 things by
"Greg Sabino Mullane" 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.
I'm having t
On Tue, Oct 20, 2009 at 10:07 AM, Greg Sabino Mullane 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 only
>>>
On Tue, Oct 20, 2009 at 9:42 AM, Tom Lane wrote:
> Magnus Hagander writes:
>> 2009/10/19 Tom Lane :
>>> 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
-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 o
Greg Smith 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 done weekly or mo
Magnus Hagander writes:
> 2009/10/19 Tom Lane :
>> 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 change the name
> of a user, but
On Tue, Oct 13, 2009 at 4:11 PM, Andrew Dunstan 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 PQsetApplicati
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
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 supportin
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 th
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 t
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, Oct 20, 2009 at 1:21 AM, Tom Lane 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 "cached_probability".
2009/10/20 Dave Page :
> On Mon, Oct 19, 2009 at 9:34 PM, Magnus Hagander wrote:
>> 2009/10/19 Dave Page :
>>> On Mon, Oct 19, 2009 at 3:42 PM, Massa, Harald Armin wrote:
Would'nt this also make sense for PostgreSQL? That is, when no environment
is set, and no SET-command is issued
On Mon, Oct 19, 2009 at 9:34 PM, Magnus Hagander wrote:
> 2009/10/19 Dave Page :
>> On Mon, Oct 19, 2009 at 3:42 PM, Massa, Harald Armin wrote:
>>>
>>> Would'nt this also make sense for PostgreSQL? That is, when no environment
>>> is set, and no SET-command is issued, that the application name be
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 continu
2009/10/19 Tom Lane :
> 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
> hazard fo
Aidan Van Dyk wrote:
> * Tom Lane [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), but any s
90 matches
Mail list logo
