Re: [HACKERS] .gitignore files, take two

On Tue, Sep 21, 2010 at 12:55 AM, Robert Haas wrote: > All the build products in a normal build. One of the infelicities of > git is that 'git status' shows the untracked files at the bottom. So > if you have lots of unignored stuff floating around, the information > about which files you've ac

Re: [HACKERS] .gitignore files, take two

James Cloos writes: > I'm reading this a bit late, but... > We (Xorg) found that ignoring: >*~ >*.bak >*.patch > in addition to the files generated by building is very helpful. Yeah ... personally I'm ignoring *~ and *.orig. I think that the consensus among pgsql-hackers was that t

Re: [HACKERS] .gitignore files, take two

I'm reading this a bit late, but... We (Xorg) found that ignoring: *~ *.bak *.patch in addition to the files generated by building is very helpful. We do use git tag and git describe in the make dist process, as well as git log >ChangeLog. That may be relevant; avoiding git describe's

Re: archives, attachments, etc (was: [HACKERS] Patch to add a primary key using an existing index)

On Sat, Oct 9, 2010 at 3:30 PM, Dimitri Fontaine wrote: > Andrew Dunstan writes: > > I wish we could get the archive processor to provide access to the > > attachments even if they have a MIME type of text/whatever. That's a > > horrid inefficiency. Maybe we could restrict it to text attachments

archives, attachments, etc (was: [HACKERS] Patch to add a primary key using an existing index)

Andrew Dunstan writes: > I wish we could get the archive processor to provide access to the > attachments even if they have a MIME type of text/whatever. That's a > horrid inefficiency. Maybe we could restrict it to text attachments > that have a Content-Type with a name attribute that contains th

Re: [HACKERS] Patch to add a primary key using an existing index

On 10/09/2010 02:19 PM, Gurjeet Singh wrote: On Sat, Oct 9, 2010 at 2:07 PM, Gurjeet Singh > wrote: This is a continuation from this thread: http://archives.postgresql.org/pgsql-hackers/2010-09/msg02153.php The attached patch allows creating a prima

Re: [HACKERS] Patch to add a primary key using an existing index

On Sat, Oct 9, 2010 at 2:07 PM, Gurjeet Singh wrote: > This is a continuation from this thread: > http://archives.postgresql.org/pgsql-hackers/2010-09/msg02153.php > > The attached patch allows creating a primary key using an existing index. > > I have attached two versions of the patch: one is

Re: [HACKERS] getting set up on git (finally)

On 10/08/2010 08:12 PM, Robert Haas wrote: > On Fri, Oct 8, 2010 at 4:31 PM, Joe Conway wrote: >> I'm finally trying to get current with the switch to git, following this >> wiki page: >> >> http://wiki.postgresql.org/wiki/Committing_with_Git >> >> Specifically, I am trying to do: >>

Re: [HACKERS] compiling C library under mingw

It is an exe don't I need a dll? Can you get more specific on "either directly or by manually creating an import library"? What I understand by directly is that I should rename postgres.exe to postgres.dll. Thank you for responding so quickly. On Sat, Oct 9, 2010 at 12:44 PM, Magnus Hagander wrote

Re: [HACKERS] compiling C library under mingw

You need to link to postgres.exe - either directly or by manually creating an import library. //Magnus On Sat, Oct 9, 2010 at 11:40, Marios Vodas wrote: > I did a little search and I found that probably there is a library (dll or > lib ???) that contains all these references. I could specify it

Re: [HACKERS] compiling C library under mingw

I did a little search and I found that probably there is a library (dll or lib ???) that contains all these references. I could specify it by using -L/C/path/to/libraries -libraryname as an option to the second gcc command, but I have no idea what the library is and where to find it (I used -L/C/Po

Re: [HACKERS] Sync Replication with transaction-controlled durability

On Fri, 2010-10-08 at 12:23 -0400, Robert Haas wrote: > It seems like it would be more helpful if you were working on > implementing a design that had more than one vote. As far as I can > tell, we have rough consensus that for the first commit we should only > worry about the case where k = 1; t