On Wed, Jan 20, 2016 at 1:37 PM, Michael Paquier
wrote:
> On Wed, Jan 20, 2016 at 1:34 PM, Bruce Momjian wrote:
>> On Mon, Jan 4, 2016 at 09:50:40PM -0800, Michael Paquier wrote:
>>> On Tue, Jan 5, 2016 at 2:27 PM, Tom Lane
On Mon, Jan 4, 2016 at 09:50:40PM -0800, Michael Paquier wrote:
> On Tue, Jan 5, 2016 at 2:27 PM, Tom Lane wrote:
> > Michael Paquier writes:
> >> The patch would put the buildfarm in red as it is incomplete anyway,
> >> with MSVC what is used
On Wed, Jan 20, 2016 at 1:34 PM, Bruce Momjian wrote:
> On Mon, Jan 4, 2016 at 09:50:40PM -0800, Michael Paquier wrote:
>> On Tue, Jan 5, 2016 at 2:27 PM, Tom Lane wrote:
>> > Michael Paquier writes:
>> >> The patch would put the
On 01/05/2016 09:18 AM, Chapman Flack wrote:
> On 01/05/2016 12:53 AM, Michael Paquier wrote:
>
>> That's not a mandatory fix, but I think we had better do it. As long
>> as dynloader.h is copied in include/, there is no need to keep the
>> tweak of dfmgr.c to include the definitions those
On 01/05/2016 12:53 AM, Michael Paquier wrote:
> That's not a mandatory fix, but I think we had better do it. As long
> as dynloader.h is copied in include/, there is no need to keep the
> tweak of dfmgr.c to include the definitions those routines.
Looking at what you changed, all becomes clear.
On Tue, Jan 5, 2016 at 2:50 PM, Michael Paquier
wrote:
> On Tue, Jan 5, 2016 at 2:27 PM, Tom Lane wrote:
>> Michael Paquier writes:
>>> The patch would put the buildfarm in red as it is incomplete anyway,
>>> with MSVC
On Tue, Jan 5, 2016 at 11:24 PM, Chapman Flack wrote:
> On 01/05/2016 09:18 AM, Chapman Flack wrote:
>> On 01/05/2016 12:53 AM, Michael Paquier wrote:
>>
>>> That's not a mandatory fix, but I think we had better do it. As long
>>> as dynloader.h is copied in include/, there
On Wed, Jan 6, 2016 at 7:47 AM, Michael Paquier
wrote:
> By the way, it is definitely wiser to wait for after the release of
> 9.5.0 to push that or something similar...
And I have added an entry in the CF app, let's not lose track of this item:
Michael Paquier writes:
> The patch would put the buildfarm in red as it is incomplete anyway,
> with MSVC what is used instead of dynloader.h is
> port/dynloader/win32.h. Instead of this patch I would be incline to
> remove the #define stuff with dynloader.h that use
On Tue, Jan 5, 2016 at 2:27 PM, Tom Lane wrote:
> Michael Paquier writes:
>> The patch would put the buildfarm in red as it is incomplete anyway,
>> with MSVC what is used instead of dynloader.h is
>> port/dynloader/win32.h. Instead of this patch I
On 01/05/16 00:18, Michael Paquier wrote:
> with MSVC what is used instead of dynloader.h is
> port/dynloader/win32.h.
Seems like a good catch - AFAICS, what happens with port/dynloader
is that for 12 different OSes, there's an .h file there to
be copied _renamed to dynloader.h_ into the build
On Mon, Jan 4, 2016 at 9:37 PM, Chapman Flack wrote:
> On 01/05/16 00:18, Michael Paquier wrote:
>
>> with MSVC what is used instead of dynloader.h is
>> port/dynloader/win32.h.
>
> Seems like a good catch - AFAICS, what happens with port/dynloader
> is that for 12
On Mon, Jan 4, 2016 at 10:06 AM, Bruce Momjian wrote:
> On Mon, Jan 4, 2016 at 12:59:26PM -0500, Tom Lane wrote:
>> Bruce Momjian writes:
>> > On Sun, Jan 3, 2016 at 12:35:02PM -0500, Tom Lane wrote:
>> >> If we're willing to allow 9.4.6 to install different
On Sun, Jan 3, 2016 at 12:35:02PM -0500, Tom Lane wrote:
> Robert Haas writes:
> > On Dec 31, 2015, at 1:04 PM, Bruce Momjian wrote:
> >> Let's hold this for 9.5.1 and all minor releases will get it at the same
> >> time.
>
> > I vote for going ahead
Bruce Momjian writes:
> On Sun, Jan 3, 2016 at 12:35:02PM -0500, Tom Lane wrote:
>> If we're willing to allow 9.4.6 to install different files than 9.4.5
>> does, I don't see why it's a problem for 9.5.1. But having said that,
>> I agree that this seems pretty low-risk, and so
On Mon, Jan 4, 2016 at 12:59:26PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Sun, Jan 3, 2016 at 12:35:02PM -0500, Tom Lane wrote:
> >> If we're willing to allow 9.4.6 to install different files than 9.4.5
> >> does, I don't see why it's a problem for 9.5.1. But
On Dec 31, 2015, at 1:04 PM, Bruce Momjian wrote:
>> On Thu, Dec 31, 2015 at 12:50:13AM -0500, Bruce Momjian wrote:
>>> On Wed, Dec 30, 2015 at 11:57:45PM -0500, Tom Lane wrote:
>>> Bruce Momjian writes:
Oops. Once this patch is applied, it is only going
Robert Haas writes:
> On Dec 31, 2015, at 1:04 PM, Bruce Momjian wrote:
>> Let's hold this for 9.5.1 and all minor releases will get it at the same
>> time.
> I vote for going ahead with this at once. It seems low risk, and having 9.5.1
> install
On Thu, Dec 31, 2015 at 12:50:13AM -0500, Bruce Momjian wrote:
> On Wed, Dec 30, 2015 at 11:57:45PM -0500, Tom Lane wrote:
> > Bruce Momjian writes:
> > > Oops. Once this patch is applied, it is only going to take effect when
> > > someone _installs_ Postgres. Even an initdb
On Thu, Dec 31, 2015 at 04:41:44PM -0500, Chapman Flack wrote:
> I suppose there really won't be a way to do this with reliability
> unless someday extensions can hook the dependency infrastructure,
> as you mentioned in passing in an earlier message.
>
> That sounds like a longer discussion. But
On 12/31/15 16:13, Tom Lane wrote:
>> I see that 9.5.0 already adds PGDLLIMPORT on the global variable
>> creating_extension, but CurrentExtensionObject on the very next
>> line of extension.h still doesn't have it.
>
> Why would you need to access that?
This returns to the earlier question
While on the subject of things that could make it or not into 9.5.?,
I see that 9.5.0 already adds PGDLLIMPORT on the global variable
creating_extension, but CurrentExtensionObject on the very next
line of extension.h still doesn't have it.
The simplest way I've come up with in Windows to
Chapman Flack writes:
> I see that 9.5.0 already adds PGDLLIMPORT on the global variable
> creating_extension, but CurrentExtensionObject on the very next
> line of extension.h still doesn't have it.
Why would you need to access that?
regards, tom
Bruce Momjian wrote:
> On Tue, Dec 29, 2015 at 02:08:19PM -0500, Bruce Momjian wrote:
> > In the Windows MSVC build, we handle pg_config_os.h in the Perl scripts,
> > but not dynloader.h. The attached patch copies the process used for
> > pg_config_os.h to handle dynloader.h. I believe this is
On Wed, Dec 30, 2015 at 11:57:45PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > Oops. Once this patch is applied, it is only going to take effect when
> > someone _installs_ Postgres. Even an initdb will not add the file.
> > This means that upgrading to the next minor
Bruce Momjian writes:
> Oops. Once this patch is applied, it is only going to take effect when
> someone _installs_ Postgres. Even an initdb will not add the file.
> This means that upgrading to the next minor release will _not_ fix this.
Uh, what? Surely an upgrade to a
On Wed, Dec 30, 2015 at 11:18:45PM -0300, Alvaro Herrera wrote:
> > This suggests that we perhaps should consider this for 9.5.0, and that
> > your hack will have to be active until 9.4 gets to end-of-life, or
> > perhaps 9.5 if we can't get this into 9.5.0. People who are using 9.5
> > Beta or
On Tue, Dec 29, 2015 at 02:08:19PM -0500, Bruce Momjian wrote:
> In the Windows MSVC build, we handle pg_config_os.h in the Perl scripts,
> but not dynloader.h. The attached patch copies the process used for
> pg_config_os.h to handle dynloader.h. I believe this is the only *.h
> file that has
On 12/30/15 20:40, Bruce Momjian wrote:
> your hack will have to be active until 9.4 gets to end-of-life, or
> perhaps 9.5 if we can't get this into 9.5.0. People who are using 9.5
> Beta or RC will still not have the file, meaning 9.5 end-of-life might
> still be a requirement.
... by which
On Sun, Dec 6, 2015 at 07:16:24PM +, Olson, Ken wrote:
> I have downloaded a fresh copy of the Win x64 installer
> (postgresql-9.4.5-2-windows-x64.exe) from
> http://www.enterprisedb.com/products-services-training/pgdownload. The output
> of pg_config and assodicated directory listing of
On Tue, Dec 29, 2015 at 03:01:55PM -0500, Chapman Flack wrote:
> On 12/29/15 14:08, Bruce Momjian wrote:
>
> > This should fix the PL/Java Windows build problem. I don't think I will
> > get this patch into 9.5.0 but will put it in after 9.5.0 is released and
> > it will appear in all the next
On 12/29/15 14:08, Bruce Momjian wrote:
> This should fix the PL/Java Windows build problem. I don't think I will
> get this patch into 9.5.0 but will put it in after 9.5.0 is released and
> it will appear in all the next minor version releases, including 9.5.1,
> which should happen in the next
, December 05, 2015 4:07 PM
To: Olson, Ken
Subject: Re: [HACKERS] dynloader.h missing in prebuilt package for Windows?
Ken,
Do you have a moment to respond to Bruce's questions here, about what files
*are* put into $INCLUDEDIR_SERVER by the Windows PG installer you've used, and
just what
On Fri, Dec 4, 2015 at 07:09:03PM -0500, Chapman Flack wrote:
> On 12/04/15 12:56, Bruce Momjian wrote:
> >
> > OK, good logical reason to install dynloader.h on Windows.
>
> Ah! Thanks. I was starting to wonder whether I had said something wrong
> and been sent to the bit bucket within my
On Sat, Nov 14, 2015 at 07:11:32PM -0500, Chapman Flack wrote:
> I use the PG dynloader because, hey, you guys have already done the work
> of abstracting up from 12 different platforms' variations on dlopen, and
> it seems smarter to stand on your shoulders and not reinvent that. The
> one minor
On 12/04/15 12:56, Bruce Momjian wrote:
>
> OK, good logical reason to install dynloader.h on Windows.
Ah! Thanks. I was starting to wonder whether I had said something wrong
and been sent to the bit bucket within my first two -hackers posts. :)
> What do we need to do to close this item?
Hi,
This is my first -hackers message; I've recently been putting some effort
into PL/Java since this summer (my employer published a restated IP policy
that seems much friendlier toward FOSS contributions on my own time, so
my PL/Java contributions will be seen to have ticked up since then).
Chapman Flack writes:
> Ken Olson has helped me greatly by testing on Windows, and he noticed
> something odd: #include fails on Windows when building
> an extension out-of-tree, simply because that file isn't there.
While it may indeed be a packaging bug that that file
On 11/14/15 18:18, Tom Lane wrote:
> While it may indeed be a packaging bug that that file isn't installed,
> the reason why nobody noticed before is that there doesn't seem to be
> any good reason for anything except dfmgr.c to include it. What's the
> context?
One of the most long-standing
39 matches
Mail list logo