On 25.01.19 10:39, Peter Eisentraut wrote:
On 24/01/2019 00:53, Bruce Momjian wrote:
This is a pretty complicated issue with a lot of back-story. I am
thinking Tatsuo or me will probably commit it before March.
Isn't that all the more reason to add it to the commitfest?
I added it to commit
"Jonathan S. Katz" writes:
> On 2/5/19 11:37 AM, Tom Lane wrote:
>> After further thought about that, I'm liking the idea that was
>> discussed upthread of setting up a separate git repo for the
>> aggregate release notes.
> The contrary point I will make is handling this via a different method.
On 2/5/19 12:17 PM, Andres Freund wrote:
> Hi,
>
> On 2019-02-05 12:10:57 -0500, Tom Lane wrote:
>> Andres Freund writes:
>>> On 2019-02-05 08:50:16 -0500, Jonathan S. Katz wrote:
The original thought process was to _not_ do that given the effort, but
if it's just for `/current/` it may
On 2/5/19 11:37 AM, Tom Lane wrote:
> I wrote:
>> BTW, while we're thinking about this --- I remembered that as things
>> stand, we've broken my historical practice of putting up first-draft
>> minor release notes for people to look at if they choose. Those will
>> now be in the newest back branch
Andres Freund writes:
> On 2019-02-05 12:24:00 -0500, Tom Lane wrote:
>> Huh? The release note contents are identical cross-branch.
>> I know, because I'm generally the one making them.
> The point is that links in release-$version.html in /current/ or in a
> magical new repo will likely contain
Hi,
On 2019-02-05 12:24:00 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2019-02-05 12:10:57 -0500, Tom Lane wrote:
> >> For something like release-9-6-10.html, there's no value in having it
> >> appear in three or four different places. You can't even argue that
> >> the later branches
Andres Freund writes:
> On 2019-02-05 12:10:57 -0500, Tom Lane wrote:
>> For something like release-9-6-10.html, there's no value in having it
>> appear in three or four different places. You can't even argue that
>> the later branches might be more up-to-date: that text is *the same*,
>> modulo
Hi,
On 2019-02-05 12:10:57 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2019-02-05 08:50:16 -0500, Jonathan S. Katz wrote:
> >> The original thought process was to _not_ do that given the effort, but
> >> if it's just for `/current/` it may not be so bad.
>
> > I think it definitely sho
Andres Freund writes:
> On 2019-02-05 08:50:16 -0500, Jonathan S. Katz wrote:
>> The original thought process was to _not_ do that given the effort, but
>> if it's just for `/current/` it may not be so bad.
> I think it definitely should also be on /devel/, that's what's out there
> on blog posts
On 2019-02-05 09:12:56 -0500, Tom Lane wrote:
> Andres Freund writes:
> > For the record: I think this is a terrible idea. Makes it much harder to
> > figure out what changed when, and requires per-branch incantations to
> > grep through the log.
>
> Uh ... "grep through the log"? The git log ou
On 2019-02-05 08:50:16 -0500, Jonathan S. Katz wrote:
> On 2/5/19 1:02 AM, Andres Freund wrote:
> > Hi,
> >
> > On 2019-01-26 10:06:06 -0500, Tom Lane wrote:
> >> "Jonathan S. Katz" writes:
> >>> The one "caveat" I will bring up is that once pushed and applied to the
> >>> site, we would bring in
I wrote:
> BTW, while we're thinking about this --- I remembered that as things
> stand, we've broken my historical practice of putting up first-draft
> minor release notes for people to look at if they choose. Those will
> now be in the newest back branch, which we don't have an automatic
> build
"Jonathan S. Katz" writes:
> On 2/5/19 9:12 AM, Tom Lane wrote:
>> Anyway, if people want something resembling the old presentation,
>> I think the way to get there is to have some sort of aggregate
>> release notes in a separate place on the web site. We'd discussed
>> that briefly upthread, but
An IDENTITY column is automatically NOT NULL - which is per SQL standard.
I think this should be documented in sql-createtable.html. The same is
currently documented for PRIMARY KEY constraints:
https://www.postgresql.org/docs/devel/sql-createtable.html
> PRIMARY KEY enforces the same data const
On 2/5/19 9:12 AM, Tom Lane wrote:
> Anyway, if people want something resembling the old presentation,
> I think the way to get there is to have some sort of aggregate
> release notes in a separate place on the web site. We'd discussed
> that briefly upthread, but no one's volunteered to push it
Andres Freund writes:
> For the record: I think this is a terrible idea. Makes it much harder to
> figure out what changed when, and requires per-branch incantations to
> grep through the log.
Uh ... "grep through the log"? The git log output hasn't changed at all.
I've personally never found t
On 2/5/19 1:02 AM, Andres Freund wrote:
> Hi,
>
> On 2019-01-26 10:06:06 -0500, Tom Lane wrote:
>> "Jonathan S. Katz" writes:
>>> The one "caveat" I will bring up is that once pushed and applied to the
>>> site, we would bring introduce a lot of 404s into the website.
>>
>> Hm. In principle we c
On 2019-Feb-04, Andres Freund wrote:
> Gah, I'd skipped this thread, because I was OK, if not happy, about the
> original modest proposal (trimming to supported versions). My fault.
>
> For the record: I think this is a terrible idea.
+1 I don't like it either. The original idea of just removi
18 matches
Mail list logo