Peter Eisentraut wrote:
On Thursday 02 April 2009 21:38:06 Tom Lane wrote:
Heikki Linnakangas 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 di
On Thursday 02 April 2009 21:38:06 Tom Lane wrote:
> Heikki Linnakangas 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
Tom Lane 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
Peter Eisentraut 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 stud
Peter Eisentraut 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,
On Sunday 05 April 2009 05:00:04 Tom Lane wrote:
> Chris Browne writes:
> > j...@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:
Chris Browne writes:
> j...@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 th
Josh Berkus 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-domain
Heikki Linnakangas 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-databas
Bruce Momjian wrote:
Tom Lane wrote:
Magnus Hagander 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
Dave Page wrote:
> On Thu, Apr 2, 2009 at 3:46 PM, Tom Lane wrote:
> > Dave Page 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
On Thu, Apr 2, 2009 at 3:46 PM, Tom Lane wrote:
> Dave Page 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
Tom Lane wrote:
> Dave Page 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
Tom Lane wrote:
> Magnus Hagander 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
Dave Page 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, bu
Magnus Hagander 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 opt
On Thu, Apr 2, 2009 at 3:23 PM, 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
Tom Lane wrote:
> Dave Page writes:
>> On Thu, Apr 2, 2009 at 8:47 AM, Heikki Linnakangas
>> 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 vers
Dave Page writes:
> On Thu, Apr 2, 2009 at 8:47 AM, Heikki Linnakangas
> 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 sho
Dave Page wrote:
> On Thu, Apr 2, 2009 at 8:47 AM, Heikki Linnakangas
> 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 Thu, Apr 2, 2009 at 8:47 AM, Heikki Linnakangas
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
Robert Haas wrote:
On Sat, Mar 28, 2009 at 12:25 PM, Tom Lane wrote:
Robert Haas writes:
On Fri, Mar 27, 2009 at 11:42 AM, Tom Lane 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 opt
On Sat, Mar 28, 2009 at 12:25 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Mar 27, 2009 at 11:42 AM, Tom Lane 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
j...@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 assume
On Sat, Mar 28, 2009 at 4:25 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Mar 27, 2009 at 11:42 AM, Tom Lane 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 C
Robert Haas writes:
> On Fri, Mar 27, 2009 at 11:42 AM, Tom Lane 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 DATAB
On Fri, Mar 27, 2009 at 11:42 AM, Tom Lane 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
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), whic
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 matte
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.
Josh Berkus 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
On Fri, Mar 27, 2009 at 1:46 PM, Josh Berkus wrote:
> All,
>
>> On Fri, Mar 27, 2009 at 2:58 AM, Robert Haas
>> 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
All,
On Fri, Mar 27, 2009 at 2:58 AM, Robert Haas 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 Data
On Fri, Mar 27, 2009 at 11:42 AM, Tom Lane 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
Robert Haas 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
On Thu, Mar 26, 2009 at 11:06 PM, Guillaume Smet
wrote:
> On Fri, Mar 27, 2009 at 2:58 AM, Robert Haas 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
On Fri, Mar 27, 2009 at 9:38 AM, Magnus Hagander 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
On Fri, Mar 27, 2009 at 4:24 AM, Robert Haas 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
--
Sent via pgsql
On Fri, Mar 27, 2009 at 2:58 AM, Robert Haas 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 ite
Guillaume Smet wrote:
> On Fri, Mar 27, 2009 at 2:58 AM, Robert Haas 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
On Thu, Mar 26, 2009 at 10:11 PM, Bruce Momjian 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 Nov
On Fri, Mar 27, 2009 at 2:58 AM, Robert Haas 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
Robert Haas writes:
> On Thu, Mar 26, 2009 at 10:11 PM, Bruce Momjian 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 thi
Robert Haas wrote:
> On Thu, Mar 26, 2009 at 9:36 PM, Bruce Momjian 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
> > re
On Thu, Mar 26, 2009 at 9:36 PM, Bruce Momjian 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
Magnus Hagander writes:
> Tom Lane wrote:
>> http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items
>> Anybody who wants to start cleaning these things up, have at it.
> We were in agreement to move the Win32 namespace issue to the TODO list,
> right? Unless anybody objects, I'll go ahead and
Tom Lane wrote:
> Since Bruce seems not to be in a hurry to update his open-items mailbox,
> I've taken the liberty of adding entries for all the items that I think
> are relevant for 8.4 to the wiki page:
> http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items
>
> Anybody who wants to start c
Since Bruce seems not to be in a hurry to update his open-items mailbox,
I've taken the liberty of adding entries for all the items that I think
are relevant for 8.4 to the wiki page:
http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items
Anybody who wants to start cleaning these things up, hav
48 matches
Mail list logo
