Thread: Re: 8.4 open items list
On Thu, Mar 26, 2009 at 9:36 PM, Bruce Momjian <bruce@momjian.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@momjian.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@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Mar 26, 2009 at 10:11 PM, Bruce Momjian <bruce@momjian.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 2:58 AM, Robert Haas <robertmhaas@gmail.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@momjian.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
Guillaume Smet wrote: > On Fri, Mar 27, 2009 at 2:58 AM, Robert Haas <robertmhaas@gmail.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 2:58 AM, Robert Haas <robertmhaas@gmail.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
On Fri, Mar 27, 2009 at 4:24 AM, Robert Haas <robertmhaas@gmail.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
On Fri, Mar 27, 2009 at 9:38 AM, Magnus Hagander <magnus@hagander.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 Thu, Mar 26, 2009 at 11:06 PM, Guillaume Smet <guillaume.smet@gmail.com> wrote: > On Fri, Mar 27, 2009 at 2:58 AM, Robert Haas <robertmhaas@gmail.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@gmail.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@sss.pgh.pa.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@gmail.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
limitingnumber 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@agliodbs.com> wrote: > All, > >> On Fri, Mar 27, 2009 at 2:58 AM, Robert Haas<robertmhaas@gmail.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@agliodbs.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@momjian.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@sai.msu.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@sss.pgh.pa.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@gmail.com> writes:
> On Fri, Mar 27, 2009 at 11:42 AM, Tom Lane <tgl@sss.pgh.pa.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@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Fri, Mar 27, 2009 at 11:42 AM, Tom Lane <tgl@sss.pgh.pa.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@agliodbs.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@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Fri, Mar 27, 2009 at 11:42 AM, Tom Lane <tgl@sss.pgh.pa.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@sss.pgh.pa.us> wrote: >> Robert Haas <robertmhaas@gmail.com> writes: >>> On Fri, Mar 27, 2009 at 11:42 AM, Tom Lane <tgl@sss.pgh.pa.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.linnakangas@enterprisedb.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.linnakangas@enterprisedb.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@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Dave Page <dpage@pgadmin.org> writes:
> On Thu, Apr 2, 2009 at 8:47 AM, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.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@pgadmin.org> writes: >> On Thu, Apr 2, 2009 at 8:47 AM, Heikki Linnakangas >> <heikki.linnakangas@enterprisedb.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@sss.pgh.pa.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@hagander.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@pgadmin.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@hagander.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@momjian.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@pgadmin.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@momjian.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@sss.pgh.pa.us> wrote: > Dave Page <dpage@pgadmin.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@sss.pgh.pa.us> wrote: > > Dave Page <dpage@pgadmin.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@momjian.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@hagander.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.linnakangas@enterprisedb.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@agliodbs.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@acm.org> writes: > josh@agliodbs.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@acm.org> writes: > > josh@agliodbs.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@gmx.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@gmx.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@sss.pgh.pa.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
----------------------------------------------------------------------<язык
значение="русский"/>
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.linnakangas@enterprisedb.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.linnakangas@enterprisedb.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