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
"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
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
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
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
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
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
>
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
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
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
12 matches
Mail list logo
