Re: 8.4 open items list

On Thu, Mar 26, 2009 at 9:36 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> I'm sure they will.  But the current problem is getting beta released
>> in the first place, and AFAICS we're all waiting for you.
>
> As Tom said, it is more the open items that we are waiting on, not the
> release notes, but if if you are waiting for me to generate a list of
> open items, I already published in inaccurate list that at least
> _includes_ all the open items, plus lots of stuff that isn't open.

Hmm, well, Tom dropped a filtered version of your list into the open
items wiki page.

http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items

That includes a whole slough of patches that weren't submitted until
after November 1st and which I think should probably be bumped en
masse to 8.5:

Change behavior of statement-level triggers for inheritance cases?
GetCurrentVirtualXIDs() (is this patch safe?)
PQinitSSL broken in some use cases
postgresql.conf: patch to have ParseConfigFile report all parsing
errors, then bail
small but useful patches for text search
Additional DTrace Probes
pg_standby trigger behavior is dangerous
psql \d commands and information_schema (already in CommitFest 2009-First)
Have \d show child tables that inherit from the specified parent
(already in CommitFest 2009-First)

I think we should also boot everything in the "pre-existing bugs"
category, and the first two items from the "questions" category, which
don't seem important enough to worry about at this stage of the game.
That would leave us with 14 items, all of which look reasonably
relevant and 8.4-related.

Comments?

...Robert

Robert Haas wrote:
> On Thu, Mar 26, 2009 at 9:36 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> >> I'm sure they will. ?But the current problem is getting beta released
> >> in the first place, and AFAICS we're all waiting for you.
> >
> > As Tom said, it is more the open items that we are waiting on, not the
> > release notes, but if if you are waiting for me to generate a list of
> > open items, I already published in inaccurate list that at least
> > _includes_ all the open items, plus lots of stuff that isn't open.
>
> Hmm, well, Tom dropped a filtered version of your list into the open
> items wiki page.
>
> http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items
>
> That includes a whole slough of patches that weren't submitted until
> after November 1st and which I think should probably be bumped en
> masse to 8.5:
>
> Change behavior of statement-level triggers for inheritance cases?
> GetCurrentVirtualXIDs() (is this patch safe?)
> PQinitSSL broken in some use cases
> postgresql.conf: patch to have ParseConfigFile report all parsing
> errors, then bail
> small but useful patches for text search
> Additional DTrace Probes
> pg_standby trigger behavior is dangerous
> psql \d commands and information_schema (already in CommitFest 2009-First)
> Have \d show child tables that inherit from the specified parent
> (already in CommitFest 2009-First)

Wow, that is a large list. Getting this all on a wiki is really what
needed to happen. I can't keep an open list current enough to be
useful.

> I think we should also boot everything in the "pre-existing bugs"
> category, and the first two items from the "questions" category, which
> don't seem important enough to worry about at this stage of the game.
> That would leave us with 14 items, all of which look reasonably
> relevant and 8.4-related.

I think pushing "pre-existing bugs" to 8.5 is a mistake, first from a
software quality standpoint, and second because we are going to have a
lots of downtime during beta while we wait for feedback, so we can work
on some of these issues then. These things are not going to be any
easier to fix during 8.5 than now so let's make 8.4 as good as we can
without overly-delaying it.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Fri, Mar 27, 2009 at 2:58 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> That includes a whole slough of patches that weren't submitted until
> after November 1st and which I think should probably be bumped en
> masse to 8.5:
>
> postgresql.conf: patch to have ParseConfigFile report all parsing
> errors, then bail

Not sure about this one. A similar patch for the pg_hba.conf file
submitted after the commit fest (IIRC) has already been commited.

> pg_standby trigger behavior is dangerous

This one has to be fixed IMHO. I'm not sure how but we have to take a
decision. The current behaviour is really dangerous for most of our
users.

--
Guillaume

On Thu, Mar 26, 2009 at 10:11 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> Hmm, well, Tom dropped a filtered version of your list into the open
>> items wiki page.
>>
>> http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items
>>
>> That includes a whole slough of patches that weren't submitted until
>> after November 1st and which I think should probably be bumped en
>> masse to 8.5:
>>
>> Change behavior of statement-level triggers for inheritance cases?
>> GetCurrentVirtualXIDs() (is this patch safe?)
>> PQinitSSL broken in some use cases
>> postgresql.conf: patch to have ParseConfigFile report all parsing
>> errors, then bail
>> small but useful patches for text search
>> Additional DTrace Probes
>> pg_standby trigger behavior is dangerous
>> psql \d commands and information_schema (already in CommitFest 2009-First)
>> Have \d show child tables that inherit from the specified parent
>> (already in CommitFest 2009-First)
>
> Wow, that is a large list.  Getting this all on a wiki is really what
> needed to happen.  I can't keep an open list current enough to be
> useful.

Ah, glad you like. I thought you'd been arguing the other side of
that point with me for several days, but no matter - it seems like we
might be converging on some kind of consensus here.

>> I think we should also boot everything in the "pre-existing bugs"
>> category, and the first two items from the "questions" category, which
>> don't seem important enough to worry about at this stage of the game.
>> That would leave us with 14 items, all of which look reasonably
>> relevant and 8.4-related.
>
> I think pushing "pre-existing bugs" to 8.5 is a mistake, first from a
> software quality standpoint, and second because we are going to have a
> lots of downtime during beta while we wait for feedback, so we can work
> on some of these issues then.  These things are not going to be any
> easier to fix during 8.5 than now so let's make 8.4 as good as we can
> without overly-delaying it.

What is the threshold for "has to be fixed before we can go to beta"
versus "has to be fixed before release"? I'm not opposed to fixing
the bugs, but it seems like every day that we postpone cutting a beta
is one more day until release, and so I think our immediate goal
should be to fix all of the things that need to be fixed before beta
can start.

...Robert

On Thu, Mar 26, 2009 at 11:06 PM, Guillaume Smet
<guillaume(dot)smet(at)gmail(dot)com> wrote:
> On Fri, Mar 27, 2009 at 2:58 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> That includes a whole slough of patches that weren't submitted until
>> after November 1st and which I think should probably be bumped en
>> masse to 8.5:
>>
>> postgresql.conf: patch to have ParseConfigFile report all parsing
>> errors, then bail
>
> Not sure about this one. A similar patch for the pg_hba.conf file
> submitted after the commit fest (IIRC) has already been commited.

Well, if we keep slipping one more thing in, we're never going to get
this thing out the door. The fact that we've already let some extra
things slip in is not a good reason to slip in moor things. The patch
may be great stuff and if a committer wants to pick it up and commit
it, that's their prerogative. But to my mind this sounds like an
enhancement, and since we've supposedly been in feature freeze for
almost 5 months, I see no reason to argue that it MUST happen before
beta.

>> pg_standby trigger behavior is dangerous
>
> This one has to be fixed IMHO. I'm not sure how but we have to take a
> decision. The current behaviour is really dangerous for most of our
> users.

Perhaps so, but again, it's not a new regression, so why should it be
considered a blocker for 8.4beta?

Most of these are great patches. I would love to see them committed.
But at some point you have to draw a line in the sand. A decision was
taken that the last commitfest for 8.4 began 11/1/08. We have finally
managed to END that commitfest. I don't wish to have another,
unofficial one before beta. I want to go to beta as soon as humanly
possible and try to get this release out the door sometime in 2009.

...Robert

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Mar 26, 2009 at 10:11 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> I think pushing "pre-existing bugs" to 8.5 is a mistake,

> What is the threshold for "has to be fixed before we can go to beta"
> versus "has to be fixed before release"?

I did not by any means intend that those things should wait until 8.5.
The point was that we needn't be ashamed to release an 8.4 *beta*
that has such bugs. Or at least no more than we are ashamed to have
released existing stable versions with 'em.

Beta is about getting a reasonably stable version into the hands of
testers. It's not about achieving perfection before the testers
ever see it.

regards, tom lane

On Fri, Mar 27, 2009 at 4:24 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Perhaps so, but again, it's not a new regression, so why should it be
> considered a blocker for 8.4beta?

I agree they shouldn't. You were talking about bumping them to 8.5
which is a totally different thing.

--
Guillaume

Guillaume Smet wrote:
> On Fri, Mar 27, 2009 at 2:58 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> That includes a whole slough of patches that weren't submitted until
>> after November 1st and which I think should probably be bumped en
>> masse to 8.5:
>>
>> postgresql.conf: patch to have ParseConfigFile report all parsing
>> errors, then bail
>
> Not sure about this one. A similar patch for the pg_hba.conf file
> submitted after the commit fest (IIRC) has already been commited.

That can be argued to just be completing the pg_hba rewrite stuff that
happened long before november with the final logical step.

I guess if you stretch that definition as well, this could also be an
extension to that :)

//Magnus

On Fri, Mar 27, 2009 at 9:38 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> That can be argued to just be completing the pg_hba rewrite stuff that
> happened long before november with the final logical step.
>
> I guess if you stretch that definition as well, this could also be an
> extension to that :)

Yes, that was my point. I think it's better to be consistent for all
the configuration files.

On Fri, Mar 27, 2009 at 2:58 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> I think we should also boot everything in the "pre-existing bugs"
> category, and the first two items from the "questions" category, which
> don't seem important enough to worry about at this stage of the game.
> That would leave us with 14 items, all of which look reasonably
> relevant and 8.4-related.
>
> Comments?

FWIW, I posted my comments in the wiki. I tried to post useful
information about the status of each item I have an opinion about.

--
Guillaume

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items

> That includes a whole slough of patches that weren't submitted until
> after November 1st and which I think should probably be bumped en
> masse to 8.5:

> Change behavior of statement-level triggers for inheritance cases?

Agreed: no patch submitted, not a bug (we'd never consider back-patching
such a change), and no obvious reason why it should be part of 8.4
rather than waiting.

> GetCurrentVirtualXIDs() (is this patch safe?)

This is actually an extract from the hot standby patch, so I think it's
unfair to claim it was submitted too late. If I thought it were safe
I'd apply it, but I'm not convinced.

> PQinitSSL broken in some use cases

This is a hard case. It's arguably a bug fix, but not one that we could
back-patch. I think we would have applied it by now if there were
consensus on which solution to pick.

> postgresql.conf: patch to have ParseConfigFile report all parsing
> errors, then bail

Agreed, this is in the "too late" category.

> small but useful patches for text search

Ditto.

> Additional DTrace Probes

This arguably is part of the existing 8.4 dtrace-related changes,
but it hasn't gotten any review that I saw. (And after having found
a number of problems in the earlier dtrace patches, I'm disinclined
to let it in without close review ...)

> pg_standby trigger behavior is dangerous

Another sort-of-a-bug case; I'm inclined to leave it on the list
until a bit of consensus emerges.

> psql \d commands and information_schema (already in CommitFest 2009-First)

This isn't a feature, it's a bug fix for the already committed changes
in \d's system-vs-user filtering. (Which I remain terribly unhappy with
in general, but that's a different list entry...)

> Have \d show child tables that inherit from the specified parent
> (already in CommitFest 2009-First)

Agreed, this is a new feature that can wait.

> I think we should also boot everything in the "pre-existing bugs"
> category,

Well, some of the things on this page are beta blockers and some are
just stuff that we'd like to address before final. Of the "pre existing
bugs", the only one that I'm really concerned about addressing before
beta is the polymorphic types vs. domains issue. Changing that has some
potential for breaking user apps so it'd be polite to make it happen
before beta starts. The rest should stay on the page, though, to be
addressed during beta.

> and the first two items from the "questions" category, which
> don't seem important enough to worry about at this stage of the game.

Both of those things are related to 8.4 feature changes, so we should
either do them now or decide we won't do them.

regards, tom lane

On Fri, Mar 27, 2009 at 11:42 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> PQinitSSL broken in some use cases
>
> This is a hard case.  It's arguably a bug fix, but not one that we could
> back-patch.  I think we would have applied it by now if there were
> consensus on which solution to pick.

I think the consensus we were headed towards was wrong, or at least
not completely hashed out. IMO, the correct solution to this class of
problem is a generic library initialization routine (PQinit) that can
handle things of this nature without breaking the ABI down the line.
This solution felt controversial, and I definitely don't want to hold
up 8.4 trying to get it right.

So, my vote is to document the issue for 8.4, and hopefully come up
with something better for 8.5.

merlin

All,

> On Fri, Mar 27, 2009 at 2:58 AM, Robert Haas<robertmhaas(at)gmail(dot)com> wrote:
>> I think we should also boot everything in the "pre-existing bugs"
>> category,

I don't agree. I think we should fix as many of those as we can without
holding up the release. Having been (briefly) in charge of Another Open
Source Database's bug list, I've seen where ignoring pre-existing bugs
can lead, and it's not at all pretty.

These bugs strike me as especially pernicious and to need fixing before
8.4 release (but NOT before Beta):

* GiST picksplit (maybe GIN too?) can fail
* Perl/libxml incompatibility
* BUG #4721: bad side-effects of limiting number of clauses that
predtest will consider
* BUG #4694: uppercase path problem on Windows

This one is also really bad, but probably only Doc-patchable. However,
can SQL/XML really be said to be core functionality if it only works in
UTF-8?
* BUG #4622: xpath only work in utf-8 server encoding

I'll also take a stab at this one, because it looks easy:
* contrib/intarray opclass definition needs updating

And Magnus fixed this one:
* Path separator consistency on Windows

The other "existing" bugs I think relate to extreme corner cases (e.g.
ENUMs of DOMAINS) and/or may be feature requests rather than bugs (e.g.
Cover Density Ranking) so I think can safely be put off until 8.4.1 or
later.

--Josh Berkus

On Fri, Mar 27, 2009 at 1:46 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> All,
>
>> On Fri, Mar 27, 2009 at 2:58 AM, Robert Haas<robertmhaas(at)gmail(dot)com>
>>  wrote:
>>>
>>> I think we should also boot everything in the "pre-existing bugs"
>>> category,
>
> I don't agree.  I think we should fix as many of those as we can without
> holding up the release.  Having been (briefly) in charge of Another Open
> Source Database's bug list, I've seen where ignoring pre-existing bugs can
> lead, and it's not at all pretty.

I wish to recant my previous statement. I don't want to boot them - I
just don't want to hold up beta for them.

...Robert

Josh Berkus <josh(at)agliodbs(dot)com> writes:
> And Magnus fixed this one:
> * Path separator consistency on Windows

Uh, no, that's still an open issue. Magnus put up a proposed patch that
I didn't like. I think it's arguable that we should be going the other
way: convert backslashes to slashes. Magnus's patch is the first step
towards trying to make the Windows port uniformly work with backslashes,
which is going to be an enormous mess and not worth the trouble IMHO.

regards, tom lane

It seems that we have full consensus about the following Open Items
not being material for 8.4, so I'm going to move them to the TODO
list or Commitfest 2009-First as appropriate:

* Change behavior of statement-level triggers for inheritance cases?

No patch, no interest in making it happen for 8.4 -> TODO

* PQinitSSL broken in some use cases

Arguably a bug, but Merlin was one of the instigators; since he's not
happy with where we are, it should be postponed.

* postgresql.conf: patch to have ParseConfigFile report all parsing errors, then bail

Not ready, and submitted very long past feature freeze -> commitfest

* small but useful patches for text search

Also submitted too late -> commitfest

* Have \d show child tables that inherit from the specified parent

Ditto. (The other \d issues relate to already-made 8.4 changes,
though, so they still need consideration; or else an explicit
decision that the current behavior is OK.)

regards, tom lane

Robert Haas wrote:
> > Wow, that is a large list. ?Getting this all on a wiki is really what
> > needed to happen. ?I can't keep an open list current enough to be
> > useful.
>
> Ah, glad you like. I thought you'd been arguing the other side of
> that point with me for several days, but no matter - it seems like we
> might be converging on some kind of consensus here.

I prefer to do as little as possible.

> >> I think we should also boot everything in the "pre-existing bugs"
> >> category, and the first two items from the "questions" category, which
> >> don't seem important enough to worry about at this stage of the game.
> >> That would leave us with 14 items, all of which look reasonably
> >> relevant and 8.4-related.
> >
> > I think pushing "pre-existing bugs" to 8.5 is a mistake, first from a
> > software quality standpoint, and second because we are going to have a
> > lots of downtime during beta while we wait for feedback, so we can work
> > on some of these issues then. ?These things are not going to be any
> > easier to fix during 8.5 than now so let's make 8.4 as good as we can
> > without overly-delaying it.
>
> What is the threshold for "has to be fixed before we can go to beta"
> versus "has to be fixed before release"? I'm not opposed to fixing
> the bugs, but it seems like every day that we postpone cutting a beta
> is one more day until release, and so I think our immediate goal
> should be to fix all of the things that need to be fixed before beta
> can start.

Well, we don't want to be changing user-visible behavior during beta,
but anything we would fix in a minor release can be fixed during beta
too.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Fri, 27 Mar 2009, Josh Berkus wrote:

> These bugs strike me as especially pernicious and to need fixing before 8.4
> release (but NOT before Beta):
>
> * GiST picksplit (maybe GIN too?) can fail

we have patch for recent problem raised by Sergey Konoplev (thanks Andrew for
the test case), which we're testing currently.

Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: oleg(at)sai(dot)msu(dot)su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83

On Fri, Mar 27, 2009 at 11:42 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> and the first two items from the "questions" category, which
>> don't seem important enough to worry about at this stage of the game.
>
> Both of those things are related to 8.4 feature changes, so we should
> either do them now or decide we won't do them.

Well, "Should we have a LOCALE option in CREATE DATABASE?" has to do
with making:

CREATE DATABASE foo WITH LOCALE = bar
equivalent to...
CREATE DATABASE foo WITH COLLATE = bar, CTYPE = bar

That might be nice to have, but since it's just syntactic sugar, I
disagree that it's now or never.

The second item, "Should we reject toast.fillfactor in reloptions?",
comes with a patch. I think I agree with ITAGAKI Takahiro that it
would be better to have reloptions specify a set of RELOPT_KINDs to
which they pertain rather than a single one. There are likely to be
other types of reloptions that could apply to more than one category
of objects, and duplicating the definitions is not a desirable coping
strategy. So I guess I'm in favor of applying this patch if others
are satisfied with the quality of the code (which I have looked at,
but only briefly). Given the fact that anyone who understands both
toast and fillfactor should know that they don't make sense together
(and we can also document this), I don't think too many people will
get bitten if we ignored this issue for 8.4 and then applied the patch
to 8.5, but since the code is already written, there may be no reason
to take the risk.

...Robert

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Mar 27, 2009 at 11:42 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Both of those things are related to 8.4 feature changes, so we should
>> either do them now or decide we won't do them.

> Well, "Should we have a LOCALE option in CREATE DATABASE?" has to do
> with making:

> CREATE DATABASE foo WITH LOCALE = bar
> equivalent to...
> CREATE DATABASE foo WITH COLLATE = bar, CTYPE = bar

> That might be nice to have, but since it's just syntactic sugar, I
> disagree that it's now or never.

The reason I wanted it considered now is that part of the discussion
was about whether to rename the existing options (add or remove LC_,
I forget which). Once 8.4 is out it'll be too late to reconsider that.

> The second item, "Should we reject toast.fillfactor in reloptions?",
> comes with a patch. I think I agree with ITAGAKI Takahiro that it
> would be better to have reloptions specify a set of RELOPT_KINDs to
> which they pertain rather than a single one.

+1. And this is something it'd be better to get right now than later,
since it's about an API that's meant to be used by add-on modules.

regards, tom lane

On Sat, Mar 28, 2009 at 4:25 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Fri, Mar 27, 2009 at 11:42 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Both of those things are related to 8.4 feature changes, so we should
>>> either do them now or decide we won't do them.
>
>> Well, "Should we have a LOCALE option in CREATE DATABASE?" has to do
>> with making:
>
>> CREATE DATABASE foo WITH LOCALE = bar
>> equivalent to...
>> CREATE DATABASE foo WITH COLLATE = bar, CTYPE = bar
>
>> That might be nice to have, but since it's just syntactic sugar, I
>> disagree that it's now or never.
>
> The reason I wanted it considered now is that part of the discussion
> was about whether to rename the existing options (add or remove LC_,
> I forget which).  Once 8.4 is out it'll be too late to reconsider that.

Please bear in mind that whilst these features have been going into
Postgres over the last 12 months, other people have been busy adding
support for them in tools and interfaces etc. so changing anything
even before we go to beta should not be done on a whim. This is even
worse than might be immediately apparent because we generally need to
get our code stable *before* PostgreSQL is released to ensure that
tools and interfaces are definitely ready in time - for example,
pgAdmin is already in it's second beta.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

josh(at)agliodbs(dot)com (Josh Berkus) writes:
> This one is also really bad, but probably only Doc-patchable.
> However, can SQL/XML really be said to be core functionality if it
> only works in UTF-8?
> * BUG #4622: xpath only work in utf-8 server encoding

Well, much of the definition of XML assumes the use of Unicode, so I
don't feel entirely badly about there being such a restriction.

It seems likely to me that opening its use to other encodings has a
considerable risk of breaking due to a loss of, erm, "closure," in the
mathematical sense. Or, alternatively, opening a Pandora's Box of
needing to do translations to prevent mappings from breaking.
--
let name="cbbrowne" and tld="linuxfinances.info" in String.concat "@" [name;tld];;
http://cbbrowne.com/info/languages.html
If you add a couple of i's to Microsoft's stock ticker symbol, you get
'misfit'. This is, of course, not a coincidence.

On Sat, Mar 28, 2009 at 12:25 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Fri, Mar 27, 2009 at 11:42 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Both of those things are related to 8.4 feature changes, so we should
>>> either do them now or decide we won't do them.
>
>> Well, "Should we have a LOCALE option in CREATE DATABASE?" has to do
>> with making:
>
>> CREATE DATABASE foo WITH LOCALE = bar
>> equivalent to...
>> CREATE DATABASE foo WITH COLLATE = bar, CTYPE = bar
>
>> That might be nice to have, but since it's just syntactic sugar, I
>> disagree that it's now or never.
>
> The reason I wanted it considered now is that part of the discussion
> was about whether to rename the existing options (add or remove LC_,
> I forget which).  Once 8.4 is out it'll be too late to reconsider that.

The current situation is not horribly consistent because createdb uses
--lc-foo and the SQL syntax uses FOO. I'm not sure which is better,
or whether it's worth making them consistent. As Dave Page pointed
out, other people have already started designing tools based on CVS
HEAD. At any rate, I don't think we can make LC-FOO a keyword - it
would have to be LC_FOO or something.

>> The second item, "Should we reject toast.fillfactor in reloptions?",
>> comes with a patch.  I think I agree with ITAGAKI Takahiro that it
>> would be better to have reloptions specify a set of RELOPT_KINDs to
>> which they pertain rather than a single one.
>
> +1.  And this is something it'd be better to get right now than later,
> since it's about an API that's meant to be used by add-on modules.

Hearing no objections, I guess we need a committer to pick up the
patch and consider applying. Maybe Alvaro since he did the previous
reloptions work, but I don't know if he has time.

...Robert

Robert Haas wrote:
> On Sat, Mar 28, 2009 at 12:25 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>> On Fri, Mar 27, 2009 at 11:42 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>> Both of those things are related to 8.4 feature changes, so we should
>>>> either do them now or decide we won't do them.
>>> Well, "Should we have a LOCALE option in CREATE DATABASE?" has to do
>>> with making:
>>> CREATE DATABASE foo WITH LOCALE = bar
>>> equivalent to...
>>> CREATE DATABASE foo WITH COLLATE = bar, CTYPE = bar
>>> That might be nice to have, but since it's just syntactic sugar, I
>>> disagree that it's now or never.
>> The reason I wanted it considered now is that part of the discussion
>> was about whether to rename the existing options (add or remove LC_,
>> I forget which). Once 8.4 is out it'll be too late to reconsider that.
>
> The current situation is not horribly consistent because createdb uses
> --lc-foo and the SQL syntax uses FOO. I'm not sure which is better,
> or whether it's worth making them consistent.

I pondered for a long time whether to call the options "COLLATE" and
"CTYPE", or "LC_COLLATE" and "LC_CTYPE". I went with COLLATE and CTYPE
in the end, one reason being that there was discussion on having ICU
support as an option in the future. Calling the option LC_COLLATE would
be misleading, since the collation would actually be implemented by ICU,
with no connection to the operating system LC_COLLATE environment
variable. If we get finer grained collations (column level etc.) it
would be nice to not call it "LC_COLLATE" everywhere, but just
"collation". In fact, perhaps the keyword should be "COLLATION" instead
of COLLATE? But what to do with CTYPE then?

I'm still not sure which is actually better, though. On the other hand,
now that LC_COLLATE does refer to the environment variable, it would be
nice to spell it "LC_COLLATE". I think I'm leaning more towards
LC_COLLATE now that I've lived with it for a while...

> As Dave Page pointed
> out, other people have already started designing tools based on CVS
> HEAD.

Now is the time to decide, before the PostgreSQL beta is out. I
understand the pain inflicted on tools, but I don't think that's a good
reason to not change it. People using a beta version of pgAdmin will
should understand that it's not final yet and there can be small
glitches like that.

> At any rate, I don't think we can make LC-FOO a keyword - it
> would have to be LC_FOO or something.

Yeah, LC_COLLATE is what the environment variable is called too.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

On Thu, Apr 2, 2009 at 8:47 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:

>> As Dave Page pointed
>> out, other people have already started designing tools based on CVS
>> HEAD.
>
> Now is the time to decide, before the PostgreSQL beta is out. I understand
> the pain inflicted on tools, but I don't think that's a good reason to not
> change it. People using a beta version of pgAdmin will should understand
> that it's not final yet and there can be small glitches like that.

It's not about the changes the users see, it's about invalidating the
testing that's been done on the tools & interfaces and requiring last
minute changes to be made followed by re-testing. Because of the
unpredictability of the PostgreSQL release timing, we need to work in
advance of PostgreSQL to ensure tools are going to be ready on release
day, because I'm sure you wouldn't want to delay to allow us to catch
up. For a significant percentage of the users, having a working set of
tools and interfaces with the server release is a essential.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

Dave Page wrote:
> On Thu, Apr 2, 2009 at 8:47 AM, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>
> >> As Dave Page pointed
> >> out, other people have already started designing tools based on CVS
> >> HEAD.
> >
> > Now is the time to decide, before the PostgreSQL beta is out. I understand
> > the pain inflicted on tools, but I don't think that's a good reason to not
> > change it. People using a beta version of pgAdmin will should understand
> > that it's not final yet and there can be small glitches like that.
>
> It's not about the changes the users see, it's about invalidating the
> testing that's been done on the tools & interfaces and requiring last
> minute changes to be made followed by re-testing. Because of the
> unpredictability of the PostgreSQL release timing, we need to work in
> advance of PostgreSQL to ensure tools are going to be ready on release
> day, because I'm sure you wouldn't want to delay to allow us to catch
> up. For a significant percentage of the users, having a working set of
> tools and interfaces with the server release is a essential.

We are having enough trouble getting to beta without having to concern
ourselves with what tools are using our API before beta; beta means
beta, meaning the interface is stable, but before that, anything can be
changed. If tool makers want a stable API before beta, they can ask for
that and we can debate it but I am not ready to have every change we
make pre-beta go through an API-change discussion.

We need to be sure we have an API at beta time that we can live with for
years, and having pre-beta tools affect that seems unwise; we have put
off API decisions assuming we have until beta to make them right.

If we don't have tools by beta release, then so be it; beta will be
long enough for sufficient testing before the final release.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Dave Page <dpage(at)pgadmin(dot)org> writes:
> On Thu, Apr 2, 2009 at 8:47 AM, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>> Now is the time to decide, before the PostgreSQL beta is out. I understand
>> the pain inflicted on tools, but I don't think that's a good reason to not
>> change it. People using a beta version of pgAdmin will should understand
>> that it's not final yet and there can be small glitches like that.

> It's not about the changes the users see, it's about invalidating the
> testing that's been done on the tools & interfaces and requiring last
> minute changes to be made followed by re-testing.

Personally I think the naming decision is close enough to be a coin
toss, and so either choice is fine with me. However, I think it is
Clearly Unacceptable for createdb's switches to be spelled differently
than the underlying SQL command's options. So it's not really "let's
not change this" but "which one do you consider it more important to not
change"?

regards, tom lane

Tom Lane wrote:
> Dave Page <dpage(at)pgadmin(dot)org> writes:
>> On Thu, Apr 2, 2009 at 8:47 AM, Heikki Linnakangas
>> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>>> Now is the time to decide, before the PostgreSQL beta is out. I understand
>>> the pain inflicted on tools, but I don't think that's a good reason to not
>>> change it. People using a beta version of pgAdmin will should understand
>>> that it's not final yet and there can be small glitches like that.
>
>> It's not about the changes the users see, it's about invalidating the
>> testing that's been done on the tools & interfaces and requiring last
>> minute changes to be made followed by re-testing.
>
> Personally I think the naming decision is close enough to be a coin
> toss, and so either choice is fine with me. However, I think it is
> Clearly Unacceptable for createdb's switches to be spelled differently
> than the underlying SQL command's options. So it's not really "let's
> not change this" but "which one do you consider it more important to not
> change"?

pgAdmin uses the SQL commands, not the external commands. IIRC the only
external commands that are used are pg_dump[all], pg_restore, pg_ctl and
initdb. Is initdb on the list of tools that might be changed?

//Magnus

On Thu, Apr 2, 2009 at 3:23 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Personally I think the naming decision is close enough to be a coin
> toss, and so either choice is fine with me.  However, I think it is
> Clearly Unacceptable for createdb's switches to be spelled differently
> than the underlying SQL command's options.  So it's not really "let's
> not change this" but "which one do you consider it more important to not
> change"?

In this case, createdb - however, this particular case is of very
minor impact to us. My gripe is more on the general issue of being
potentially forced to add support for a new version and beta test
tools in the same timeframe that PostgreSQL has for beta.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> Tom Lane wrote:
>> Personally I think the naming decision is close enough to be a coin
>> toss, and so either choice is fine with me. However, I think it is
>> Clearly Unacceptable for createdb's switches to be spelled differently
>> than the underlying SQL command's options. So it's not really "let's
>> not change this" but "which one do you consider it more important to not
>> change"?

> pgAdmin uses the SQL commands, not the external commands. IIRC the only
> external commands that are used are pg_dump[all], pg_restore, pg_ctl and
> initdb. Is initdb on the list of tools that might be changed?

Hm, that's a good point. initdb has these switches (and has had 'em for
a good long time):

--locale=LOCALE set default locale for new databases
--lc-collate=, --lc-ctype=, --lc-messages=LOCALE
--lc-monetary=, --lc-numeric=, --lc-time=LOCALE
set default locale in the respective category for
new databases (default taken from environment)
--no-locale equivalent to --locale=C

So createdb is consistent with longstanding history in initdb, and
that seems to mean that we should leave it alone and change
CREATE DATABASE to match (modulo underscore instead of dash).

regards, tom lane

Dave Page <dpage(at)pgadmin(dot)org> writes:
> In this case, createdb - however, this particular case is of very
> minor impact to us. My gripe is more on the general issue of being
> potentially forced to add support for a new version and beta test
> tools in the same timeframe that PostgreSQL has for beta.

I hear you, but really the only way we could promise that would be to
have a period before beta of nothing happening in the core project while
tools authors do their thing. That doesn't seem productive. We're
trying to get some parallelism here, not serialize all the development
and testing.

regards, tom lane

Tom Lane wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
> > Tom Lane wrote:
> >> Personally I think the naming decision is close enough to be a coin
> >> toss, and so either choice is fine with me. However, I think it is
> >> Clearly Unacceptable for createdb's switches to be spelled differently
> >> than the underlying SQL command's options. So it's not really "let's
> >> not change this" but "which one do you consider it more important to not
> >> change"?
>
> > pgAdmin uses the SQL commands, not the external commands. IIRC the only
> > external commands that are used are pg_dump[all], pg_restore, pg_ctl and
> > initdb. Is initdb on the list of tools that might be changed?
>
> Hm, that's a good point. initdb has these switches (and has had 'em for
> a good long time):
>
> --locale=LOCALE set default locale for new databases
> --lc-collate=, --lc-ctype=, --lc-messages=LOCALE
> --lc-monetary=, --lc-numeric=, --lc-time=LOCALE
> set default locale in the respective category for
> new databases (default taken from environment)
> --no-locale equivalent to --locale=C
>
> So createdb is consistent with longstanding history in initdb, and
> that seems to mean that we should leave it alone and change
> CREATE DATABASE to match (modulo underscore instead of dash).

Agreed, I see them back to Postgres 8.0:

8.0/pgsql/src/bin/initdb/initdb.c:
printf(_(" --lc-collate, --lc-ctype, --lc-messages=LOCALE\n"

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Tom Lane wrote:
> Dave Page <dpage(at)pgadmin(dot)org> writes:
> > In this case, createdb - however, this particular case is of very
> > minor impact to us. My gripe is more on the general issue of being
> > potentially forced to add support for a new version and beta test
> > tools in the same timeframe that PostgreSQL has for beta.
>
> I hear you, but really the only way we could promise that would be to
> have a period before beta of nothing happening in the core project while
> tools authors do their thing. That doesn't seem productive. We're
> trying to get some parallelism here, not serialize all the development
> and testing.

I am talking to Dave Page via IM; I think the best we can do is to
focus on API changes that affect tools early in the last commit-fest and
open items closing stage. The locale flags issue wasn't in the last
commit-fest but rather an item that we never really resolved during
primary development. We would have to be more focused on getting those
nailed down earlier, rather than allow them to have the same priority as
other items.

I think it would also require a new "alpha" stage where we said the tool
API was stable (mostly SQL and system catalogs). This wouldn't affect
the psql \dfS behavior, for example, but would perhaps affect the libpq
PQinitSSL() change we made last week.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Thu, Apr 2, 2009 at 3:46 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Dave Page <dpage(at)pgadmin(dot)org> writes:
>> In this case, createdb - however, this particular case is of very
>> minor impact to us. My gripe is more on the general issue of being
>> potentially forced to add support for a new version and beta test
>> tools in the same timeframe that PostgreSQL has for beta.
>
> I hear you, but really the only way we could promise that would be to
> have a period before beta of nothing happening in the core project while
> tools authors do their thing.  That doesn't seem productive.  We're
> trying to get some parallelism here, not serialize all the development
> and testing.

Agreed - I certainly don't want to see things stand still. I just
chatted with Bruce, and we discussed the idea of prioritising patches
with API changes in the last commitfest to try to make things as
painless as possible. I suggest we discuss this in Ottawa, when we
review the whole commitfest idea.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

Dave Page wrote:
> On Thu, Apr 2, 2009 at 3:46 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Dave Page <dpage(at)pgadmin(dot)org> writes:
> >> In this case, createdb - however, this particular case is of very
> >> minor impact to us. My gripe is more on the general issue of being
> >> potentially forced to add support for a new version and beta test
> >> tools in the same timeframe that PostgreSQL has for beta.
> >
> > I hear you, but really the only way we could promise that would be to
> > have a period before beta of nothing happening in the core project while
> > tools authors do their thing. ?That doesn't seem productive. ?We're
> > trying to get some parallelism here, not serialize all the development
> > and testing.
>
> Agreed - I certainly don't want to see things stand still. I just
> chatted with Bruce, and we discussed the idea of prioritising patches
> with API changes in the last commitfest to try to make things as
> painless as possible. I suggest we discuss this in Ottawa, when we
> review the whole commitfest idea.

Good. Also, as I said before, I think having the open items list on a
wiki is the best interface we are going to get; I can't possibily keep
such a list current myself.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian wrote:
> Tom Lane wrote:
>> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>>> Tom Lane wrote:
>>>> Personally I think the naming decision is close enough to be a coin
>>>> toss, and so either choice is fine with me. However, I think it is
>>>> Clearly Unacceptable for createdb's switches to be spelled differently
>>>> than the underlying SQL command's options. So it's not really "let's
>>>> not change this" but "which one do you consider it more important to not
>>>> change"?
>>> pgAdmin uses the SQL commands, not the external commands. IIRC the only
>>> external commands that are used are pg_dump[all], pg_restore, pg_ctl and
>>> initdb. Is initdb on the list of tools that might be changed?
>> Hm, that's a good point. initdb has these switches (and has had 'em for
>> a good long time):
>>
>> --locale=LOCALE set default locale for new databases
>> --lc-collate=, --lc-ctype=, --lc-messages=LOCALE
>> --lc-monetary=, --lc-numeric=, --lc-time=LOCALE
>> set default locale in the respective category for
>> new databases (default taken from environment)
>> --no-locale equivalent to --locale=C
>>
>> So createdb is consistent with longstanding history in initdb, and
>> that seems to mean that we should leave it alone and change
>> CREATE DATABASE to match (modulo underscore instead of dash).
>
> Agreed, I see them back to Postgres 8.0:
>
> 8.0/pgsql/src/bin/initdb/initdb.c:
> printf(_(" --lc-collate, --lc-ctype, --lc-messages=LOCALE\n"

Ok, it looks like we have a consensus on changing the CREATE DATABASE
options to LC_COLLATE and LC_CTYPE.

Now, what about the idea of providing a shorthand LOCALE='foo',
mirroring --locale=foo initdb option? It seems like a good idea, because
you almost never want to set LC_COLLATE and LC_CTYPE differently. If we
do that, should LOCALE=foo also imply a per-database lc_messages,
lc_monetary, lc_numeric and lc_time settings? It seems like it should
for the sake of consistency.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> Now, what about the idea of providing a shorthand LOCALE='foo',
> mirroring --locale=foo initdb option? It seems like a good idea, because
> you almost never want to set LC_COLLATE and LC_CTYPE differently. If we
> do that, should LOCALE=foo also imply a per-database lc_messages,
> lc_monetary, lc_numeric and lc_time settings? It seems like it should
> for the sake of consistency.

The comment upthread was that we can/should leave that for 8.5.
I agree with that at this point. I think the above proposal is
not as straightforward as it looks (in particular per-DB lc_messages
has unpleasant implications for the postmaster log) and we should
not tackle it in a hasty manner.

regards, tom lane

Josh Berkus <josh(at)agliodbs(dot)com> writes:
> The other "existing" bugs I think relate to extreme corner cases (e.g.
> ENUMs of DOMAINS) and/or may be feature requests rather than bugs (e.g.
> Cover Density Ranking) so I think can safely be put off until 8.4.1 or
> later.

As far as the polymorphic-functions-vs-domains issue goes: I don't agree
that it could be fixed in a minor release. It will change the set of
possible matches to ambiguous functions and thus could cause unexpected
application breakage. I think it's major-release material only.

However, having gone over the issue again, I think that it's also not
a small patch :-(. The thing that is concerning me is that the code
effects are not limited to the parser, as I'd first thought. For
example, all the enum support functions in enum.c assume that what
get_fn_expr_argtype() will give them is the OID of an enum type,
not of some domain over an enum type. So we'd have to look not only
at the parser but at every function accepting ANYENUM or ANYARRAY,
to see if it should be taught to look through domains.

So I'm now leaning to the position that this one is too late for 8.4,
and we should just push it to the TODO list.

regards, tom lane

Chris Browne <cbbrowne(at)acm(dot)org> writes:
> josh(at)agliodbs(dot)com (Josh Berkus) writes:
>> This one is also really bad, but probably only Doc-patchable.
>> However, can SQL/XML really be said to be core functionality if it
>> only works in UTF-8?
>> * BUG #4622: xpath only work in utf-8 server encoding

> Well, much of the definition of XML assumes the use of Unicode, so I
> don't feel entirely badly about there being such a restriction.

> It seems likely to me that opening its use to other encodings has a
> considerable risk of breaking due to a loss of, erm, "closure," in the
> mathematical sense. Or, alternatively, opening a Pandora's Box of
> needing to do translations to prevent mappings from breaking.

Is there a reason not to fix it as suggested at
http://archives.postgresql.org/pgsql-bugs/2009-02/msg00032.php
ie recode on-the-fly from database encoding to UTF8?

regards, tom lane

On Sunday 05 April 2009 05:00:04 Tom Lane wrote:
> Chris Browne <cbbrowne(at)acm(dot)org> writes:
> > josh(at)agliodbs(dot)com (Josh Berkus) writes:
> >> This one is also really bad, but probably only Doc-patchable.
> >> However, can SQL/XML really be said to be core functionality if it
> >> only works in UTF-8?
> >> * BUG #4622: xpath only work in utf-8 server encoding
> >
> > Well, much of the definition of XML assumes the use of Unicode, so I
> > don't feel entirely badly about there being such a restriction.
> >
> > It seems likely to me that opening its use to other encodings has a
> > considerable risk of breaking due to a loss of, erm, "closure," in the
> > mathematical sense. Or, alternatively, opening a Pandora's Box of
> > needing to do translations to prevent mappings from breaking.
>
> Is there a reason not to fix it as suggested at
> http://archives.postgresql.org/pgsql-bugs/2009-02/msg00032.php
> ie recode on-the-fly from database encoding to UTF8?

Probably just verifying that it works.

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On Sunday 05 April 2009 05:00:04 Tom Lane wrote:
>> Is there a reason not to fix it as suggested at
>> http://archives.postgresql.org/pgsql-bugs/2009-02/msg00032.php
>> ie recode on-the-fly from database encoding to UTF8?

> Probably just verifying that it works.

Well, I'm willing to review that patch for sanity and apply it, but
I know too little about xpath to test it creatively. Have you any
suggestions other than something like the original complaint at
http://archives.postgresql.org/pgsql-bugs/2009-01/msg00135.php
which is basically trying to use a made-up(?) non-ASCII tag name?

regards, tom lane

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On Sunday 05 April 2009 05:00:04 Tom Lane wrote:
>> Is there a reason not to fix it as suggested at
>> http://archives.postgresql.org/pgsql-bugs/2009-02/msg00032.php
>> ie recode on-the-fly from database encoding to UTF8?

> Probably just verifying that it works.

I studied this patch a bit and I'm unimpressed. It looks to me like
xml.c is absolutely chock-full of places where we pass DB-encoding
data to libxml, or vice versa. The patch only fixes a few of them,
and does so in a fairly ugly, ad-hoc fashion with lots of duplicated
code.

As near as I can tell, every place where you see an explicit cast
between char * and xmlChar * is probably broken. I think we ought
to approach this by refactoring to have all those conversions go
through subroutines, instead of blithely casting.

This is more work than I personally care to put into xml.c. Any
takers?

regards, tom lane

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> As near as I can tell, every place where you see an explicit cast
> between char * and xmlChar * is probably broken. I think we ought
> to approach this by refactoring to have all those conversions go
> through subroutines, instead of blithely casting.

There is another issue (from sql.ru forum):
seb=> select xmlelement(name язык, xmlattributes('русский' as "значение"));
xmlelement
----------------------------------------------------------------------
<язык значение="&#x440;&#x443;&#x441;&#x441;&#x43A;&#x438;&#x439;"/>

xmlattributes always encode non-latin text as html entities
server_encoding UTF8
client_encoding UTF8

This is strange behavior of libxml... i can't find documentation about this.
http://www.xmlsoft.org/examples/testWriter.c use xmlTextWriterStartDocument
and set output encoding with it. Without it, all non-latin nodes and it values
written correctly (it is UTF-8), except attribute value, this is strange, imho.

xmltype * xmlelement(XmlExprState *xmlExpr, ExprContext *econtext) from xml.c
not use xmlTextWriterStartDocument and return html entities in attribute values.

--
Sergey Burladyan

On Thursday 02 April 2009 21:38:06 Tom Lane wrote:
> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> > Now, what about the idea of providing a shorthand LOCALE='foo',
> > mirroring --locale=foo initdb option? It seems like a good idea, because
> > you almost never want to set LC_COLLATE and LC_CTYPE differently. If we
> > do that, should LOCALE=foo also imply a per-database lc_messages,
> > lc_monetary, lc_numeric and lc_time settings? It seems like it should
> > for the sake of consistency.
>
> The comment upthread was that we can/should leave that for 8.5.
> I agree with that at this point. I think the above proposal is
> not as straightforward as it looks (in particular per-DB lc_messages
> has unpleasant implications for the postmaster log) and we should
> not tackle it in a hasty manner.

Those are good points, but note that createdb already *has* a --locale option
that does something specific, so in light of your earlier argument that
createdb and CREATE DATABASE options should be the same, the possibilities for
a future CREATE DATABASE ... LOCALE=foo are already being constrained.

Peter Eisentraut wrote:
> On Thursday 02 April 2009 21:38:06 Tom Lane wrote:
>> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
>>> Now, what about the idea of providing a shorthand LOCALE='foo',
>>> mirroring --locale=foo initdb option? It seems like a good idea, because
>>> you almost never want to set LC_COLLATE and LC_CTYPE differently. If we
>>> do that, should LOCALE=foo also imply a per-database lc_messages,
>>> lc_monetary, lc_numeric and lc_time settings? It seems like it should
>>> for the sake of consistency.
>> The comment upthread was that we can/should leave that for 8.5.
>> I agree with that at this point. I think the above proposal is
>> not as straightforward as it looks (in particular per-DB lc_messages
>> has unpleasant implications for the postmaster log) and we should
>> not tackle it in a hasty manner.
>
> Those are good points, but note that createdb already *has* a --locale option
> that does something specific, so in light of your earlier argument that
> createdb and CREATE DATABASE options should be the same, the possibilities for
> a future CREATE DATABASE ... LOCALE=foo are already being constrained.

Hmm, maybe we should remove the --locale option from createdb as well,
until we can implement it in a way that will set all the lc_* settings.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com