On Tue, May 30, 2017 at 8:07 PM, Tom Lane wrote:
> Hm, but with this you're trading that problem for "is the right version
> of pg_config in my PATH?".
>
That is probably a solved problem for those who are parsing the output of
--version today.
>
> This idea might well be useful for external
On Tue, May 30, 2017 at 6:36 PM, Michael Paquier
wrote:
> On Tue, May 30, 2017 at 6:14 PM, Craig Ringer
> wrote:
> > Attached is a small patch to teach pg_config how to output a
> --version-num
> >
> > With Pg 10, parsing versions got more annoying. Especially with
> > "10beta1", "9.6beta2" etc
Craig Ringer writes:
> On 31 May 2017 9:36 am, "Michael Paquier" wrote:
>> Is the data in Makefile.global unsufficient?
> It's a pain in the butt because then you need to find or get passed the
> name of Makefile.global. Then you have to template it out into a file. Or
> parse the Makefile. Or c
On 31 May 2017 9:36 am, "Michael Paquier" wrote:
On Tue, May 30, 2017 at 6:14 PM, Craig Ringer wrote:
> Attached is a small patch to teach pg_config how to output a --version-num
>
> With Pg 10, parsing versions got more annoying. Especially with
> "10beta1", "9.6beta2" etc into the mix. It make
On Tue, May 30, 2017 at 6:14 PM, Craig Ringer wrote:
> Attached is a small patch to teach pg_config how to output a --version-num
>
> With Pg 10, parsing versions got more annoying. Especially with
> "10beta1", "9.6beta2" etc into the mix. It makes no sense to force
> tools and scripts to do this
Hi all
Attached is a small patch to teach pg_config how to output a --version-num
With Pg 10, parsing versions got more annoying. Especially with
"10beta1", "9.6beta2" etc into the mix. It makes no sense to force
tools and scripts to do this when we can just expose a sensible
pre-formatted one at
On Sun, Nov 27, 2016 at 09:12:47AM -0600, Jim Nasby wrote:
> On 11/27/16 12:16 AM, Michael Paquier wrote:
> > date: Thu, 2 Jul 2015 17:24:36 -0400
> > Make numeric form of PG version number readily available in Makefiles.
>
> If you don't want to wait for that,
I wonder whether a back-patch to 9.
On Sun, Nov 27, 2016 at 03:16:37PM +0900, Michael Paquier wrote:
> On Sun, Nov 27, 2016 at 9:16 AM, David Fetter wrote:
> > While updating some extensions, I noticed that pg_config --version
> > produces output that's...maybe not quite as useful as it might be, at
> > least to a machine, so I'd li
On 11/27/16 12:16 AM, Michael Paquier wrote:
date: Thu, 2 Jul 2015 17:24:36 -0400
Make numeric form of PG version number readily available in Makefiles.
If you don't want to wait for that, you can use [1] in shell or Make to
accomplish something similar. Looks like there is a dotted MAJORVERSI
On Sun, Nov 27, 2016 at 9:16 AM, David Fetter wrote:
> While updating some extensions, I noticed that pg_config --version
> produces output that's...maybe not quite as useful as it might be, at
> least to a machine, so I'd like to throw out some proposals to fix the
> situation.
>
> Add a --ve
Folks,
While updating some extensions, I noticed that pg_config --version
produces output that's...maybe not quite as useful as it might be, at
least to a machine, so I'd like to throw out some proposals to fix the
situation.
Add a --version-numeric option to pg_config
or
Replace the cur
On 21/07 06.57, Robert Haas wrote:
> On Tue, Jul 20, 2010 at 10:52 PM, Amber wrote:
> > I am trying to build RPostgreSQL on Solaris 10u7 X64, but have problems
> > with pg_config, the configure script of RPostgreSQL checks for pg_config and
> > got ?checking for pg_config... /usr/bin/pg_config?.
On Tue, Jul 20, 2010 at 10:52 PM, Amber wrote:
> I am trying to build RPostgreSQL on Solaris 10u7 X64, but have problems
> with pg_config, the configure script of RPostgreSQL checks for pg_config and
> got “checking for pg_config... /usr/bin/pg_config”. In Solaris 10u7 X64,
> three versions of Po
Hi,
I am trying to build RPostgreSQL on Solaris 10u7 X64, but have problems
with pg_config, the configure script of RPostgreSQL checks for pg_config and
got “checking for pg_config... /usr/bin/pg_config”. In Solaris 10u7 X64,
three versions of PostgreSQL are installed, there are in
/usr/postgres/8
Tom Lane wrote:
Not sure if we should try to do anything about this --- if the file is
not there, it isn't going to help a lot for pg_config to print out where
it should have been, so really there's not much functionality loss
involved here.
A check if the GetShortPathName produces an empty file
Bruce Momjian wrote:
Mark Kirkwood wrote:
What if we add an option to initdb to allow the user to specify the name
and location of the postgresql.conf file?
That is certainly a way to approach it, I see the tough bit being the
parsing of postgresql.conf to figure out which parts of the globa
Mark Kirkwood wrote:
> > What if we add an option to initdb to allow the user to specify the name
> > and location of the postgresql.conf file?
>
> That is certainly a way to approach it, I see the tough bit being the
> parsing of postgresql.conf to figure out which parts of the global
> include
Bruce Momjian wrote:
Lamar Owen wrote:
On Monday 27 February 2006 21:09, Bruce Momjian wrote:
One question I have is how this feature would be an improvement over
just pointing pg_ctl at a postgresql.conf configuration file. That
config file has the ability to specify most if not all server
Christopher Browne wrote:
[EMAIL PROTECTED] (Mark Kirkwood) wrote:
Do you need name, value pairs? I was thinking that something like:
# Postgres Cluster Registration
#
# PG_HOME PGDATA PORT
/usr/local/pg7.4.1 /vol01/pggeo 5435
/usr/local/pg7.4.1 /vol01/pgicdmdb 5434
/usr/local/pg7.4
Lamar Owen wrote:
> On Monday 27 February 2006 21:09, Bruce Momjian wrote:
> > One question I have is how this feature would be an improvement over
> > just pointing pg_ctl at a postgresql.conf configuration file. That
> > config file has the ability to specify most if not all server
> > parameter
On Monday 27 February 2006 21:09, Bruce Momjian wrote:
> One question I have is how this feature would be an improvement over
> just pointing pg_ctl at a postgresql.conf configuration file. That
> config file has the ability to specify most if not all server
> parameters.
The big problem is that
On Monday 27 February 2006 19:59, Josh Berkus wrote:
> > My frustration level often kills any desire to contribute to open
> > source. Sometimes, I think that open source is doomed. The various
> > projects I track and use are very frustrating, they remind me of
> > dysfunctional engineering depart
[EMAIL PROTECTED] (Mark Kirkwood) wrote:
> Do you need name, value pairs? I was thinking that something like:
>
> # Postgres Cluster Registration
> #
> # PG_HOME PGDATA PORT
> /usr/local/pg7.4.1 /vol01/pggeo 5435
> /usr/local/pg7.4.1 /vol01/pgicdmdb 5434
> /usr/local/pg7.4.1 /vol03/pg7
Andrew Dunstan wrote:
Mark Kirkwood wrote:
Do you need name, value pairs? I was thinking that something like:
# Postgres Cluster Registration
#
# PG_HOME PGDATA PORT
/usr/local/pg7.4.1 /vol01/pggeo 5435
/usr/local/pg7.4.1 /vol01/pgicdmdb 5434
/usr/local/pg7.4.1 /vol03/pg74
Mark Kirkwood wrote:
Do you need name, value pairs? I was thinking that something like:
# Postgres Cluster Registration
#
# PG_HOME PGDATA PORT
/usr/local/pg7.4.1 /vol01/pggeo 5435
/usr/local/pg7.4.1 /vol01/pgicdmdb 5434
/usr/local/pg7.4.1 /vol03/pg74 5432
Clearly oth
Mark Woodward wrote:
Mark Woodward wrote:
After takin a swig o' Arrakan spice grog, [EMAIL PROTECTED] ("Mark
Woodward") belched out:
I'm not keen on the Windows .ini file style sectioning; that makes it
look like a mix between a shell script and something else. It should
be one or the other
> Mark Woodward wrote:
>>>After takin a swig o' Arrakan spice grog, [EMAIL PROTECTED] ("Mark
>>>Woodward") belched out:
>
>>>I'm not keen on the Windows .ini file style sectioning; that makes it
>>>look like a mix between a shell script and something else. It should
>>>be one or the other. It pro
Mark Woodward wrote:
After takin a swig o' Arrakan spice grog, [EMAIL PROTECTED] ("Mark
Woodward") belched out:
I'm not keen on the Windows .ini file style sectioning; that makes it
look like a mix between a shell script and something else. It should
be one or the other. It probably should b
"Mark Woodward" <[EMAIL PROTECTED]> writes:
> If one can specify a different port than the default on the command line,
> why wouldn't a file designed to describe the server process include it. My
> intention is to include all the options available via environment or
> command lon in the file.
I t
> After takin a swig o' Arrakan spice grog, [EMAIL PROTECTED] ("Mark
> Woodward") belched out:
>>> Mark Woodward wrote:
>> Like I have repeated a number of times, sometimes, there is more than
>> one
>> database cluster on a machine. The proposed pg_clusters.conf, could look
>> like this:
>>
>> pg_
After takin a swig o' Arrakan spice grog, [EMAIL PROTECTED] ("Mark Woodward")
belched out:
>> Mark Woodward wrote:
> Like I have repeated a number of times, sometimes, there is more than one
> database cluster on a machine. The proposed pg_clusters.conf, could look
> like this:
>
> pg_clusters.con
Mark Woodward wrote:
> [TOMLANE]
> DATADIR=/vol03/pg74
> PORT=5433
> POSTMASTER=/usr/local/pg7.4.1/bin/postmaster
Seems better to me to specify PREFIX (the --prefix arg to configure)
instead of POSTMASTER, because then you can search any needed executable
there (pg_config for example). Or maybe
I don't see how this is much better than just pointing to different
configuration file for each postmaster.
---
Mark Woodward wrote:
> > One question I have is how this feature would be an improvement over
> > just pointing
> Mark Woodward wrote:
>> > Mark,
>> >
>> >> Well, I'm sure that one "could" use debian's solution, but that's the
>> >> problem, it isn't PostgreSQL's solution. Shouldn't PostgreSQL provide
>> >> the mechanisms? Will debian support FreeBSD? NetBSD? Is it in the
>> >> PostgreSQL admin manual?
>> >>
> "Mark Woodward" <[EMAIL PROTECTED]> writes:
>> My frustration level often kills any desire to contribute to open
>> source.
>> Sometimes, I think that open source is doomed. The various projects I
>> track and use are very frustrating, they remind me of dysfunctional
>> engineering departments in
Mark Woodward wrote:
> > Mark,
> >
> >> Well, I'm sure that one "could" use debian's solution, but that's the
> >> problem, it isn't PostgreSQL's solution. Shouldn't PostgreSQL provide
> >> the mechanisms? Will debian support FreeBSD? NetBSD? Is it in the
> >> PostgreSQL admin manual?
> >>
> >> We
Mark,
> My frustration level often kills any desire to contribute to open
> source. Sometimes, I think that open source is doomed. The various
> projects I track and use are very frustrating, they remind me of
> dysfunctional engineering departments in huge companies, it is very hard
> to positive
On Mon, Feb 27, 2006 at 03:38:23PM -0500, Mark Woodward wrote:
> Maybe I'm too used to working in engineering groups. I am trying to get
> input for a project. Trying to iron out what the feature set should be and
> the objectives that should be attained. BEFORE I start coding.
Well yes, the probl
"Mark Woodward" <[EMAIL PROTECTED]> writes:
> My frustration level often kills any desire to contribute to open source.
> Sometimes, I think that open source is doomed. The various projects I
> track and use are very frustrating, they remind me of dysfunctional
> engineering departments in huge com
Maybe I'm too used to working in engineering groups. I am trying to get
input for a project. Trying to iron out what the feature set should be and
the objectives that should be attained. BEFORE I start coding.
Well that is always a good idea but:
Just saying "submit a patch" is the antith
> Mark,
>
>> Well, I'm sure that one "could" use debian's solution, but that's the
>> problem, it isn't PostgreSQL's solution. Shouldn't PostgreSQL provide
>> the mechanisms? Will debian support FreeBSD? NetBSD? Is it in the
>> PostgreSQL admin manual?
>>
>> We are talking about a feature, like pg_
> On Mon, Feb 27, 2006 at 11:48:50AM -0500, Mark Woodward wrote:
>> Well, I'm sure that one "could" use debian's solution, but that's the
>> problem, it isn't PostgreSQL's solution. Shouldn't PostgreSQL provide
>> the
>> mechanisms? Will debian support FreeBSD? NetBSD? Is it in the PostgreSQL
>> ad
Mark,
> Well, I'm sure that one "could" use debian's solution, but that's the
> problem, it isn't PostgreSQL's solution. Shouldn't PostgreSQL provide
> the mechanisms? Will debian support FreeBSD? NetBSD? Is it in the
> PostgreSQL admin manual?
>
> We are talking about a feature, like pg_service.c
On Mon, Feb 27, 2006 at 11:48:50AM -0500, Mark Woodward wrote:
> Well, I'm sure that one "could" use debian's solution, but that's the
> problem, it isn't PostgreSQL's solution. Shouldn't PostgreSQL provide the
> mechanisms? Will debian support FreeBSD? NetBSD? Is it in the PostgreSQL
> admin manua
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Mark Woodward
> Sent: 27 February 2006 16:49
> To: Martijn van Oosterhout
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] pg_config, pg_service.conf,
> postgre
> On Mon, Feb 27, 2006 at 09:39:59AM -0500, Mark Woodward wrote:
>> It isn't just "an" environment variable, it is a number of variables and
>> a
>> mechanism. Besides, "profile," from an admin's perspective, is for
>> managing users, not databases.
>
> Sure, you need to control the user, group, pl
On Mon, Feb 27, 2006 at 09:39:59AM -0500, Mark Woodward wrote:
> It isn't just "an" environment variable, it is a number of variables and a
> mechanism. Besides, "profile," from an admin's perspective, is for
> managing users, not databases.
Sure, you need to control the user, group, placement of
> Mark Woodward wrote:
>> > If you require a policy, then YOU are free to choose the policy that
>> > YOU need. You're not forced to accept other peoples' policies that
>> > may conflict with things in your environment.
>>
>> The problem is that there is no mechanism through which one can
>> imple
Mark Woodward wrote:
> > If you require a policy, then YOU are free to choose the policy that
> > YOU need. You're not forced to accept other peoples' policies that
> > may conflict with things in your environment.
>
> The problem is that there is no mechanism through which one can implement
> po
Hi Martijn!
Martijn van Oosterhout [2006-02-23 13:33 +0100]:
> What I mean is that only root can run pg_createcluster (either via
> package installation or directly). At least, that's what my reading of
> the code tells me. Uless you have an pg_adoptcluster somewhere :)
Ah, right, now I know what
On Thu, Feb 23, 2006 at 12:42:52PM +0100, Martin Pitt wrote:
> > The main downside of this system is that some sysadmin pretty much
> > needs to create the clusters for everyone.
>
> What do you mean in particular? The packages install a default cluster
> (e. g. postgresql-8.1 creates a cluster 8.
Hi Mark, hi Martijn!
Martijn van Oosterhout [2006-02-23 12:10 +0100]:
> If you're talking about standards perhaps you should consider how
> Debian does it. All configuration is stored in
>
> /etc/postgresql///
>
> It provides wrapper scripts to run pg_ctl (pg_ctlcluster) on any
> particular clu
On Wed, Feb 22, 2006 at 09:22:14AM -0500, Mark Woodward wrote:
> That's not the issue.
> I find it frustrating sometimes because when I describe one scenario,
> people debate it using other scenarios. Maybe I lack the communications
> skills to convey the problem accurately.
> Now, if there were
Mark Woodward wrote:
Admittedly, given that the binaries are likely to be in the
cluster-owners default PATH, it is not as hard to find them as the data
directory. However, this is all about convenience it would seem, since
(for many *nix platforms) two simple searches will give you most of wh
On Wed, 22 Feb 2006, Mark Woodward wrote:
> > Mark Woodward wrote:
> >
> >> I'm not sure that I agree. At least in my experience, I wouldn't have
> >> more
> >> than one installation of PostgreSQL in a production machine. It is
> >> potentially problematic.
> >>
> >
> > I agree with you for produ
> Mark Woodward wrote:
>
>> I'm not sure that I agree. At least in my experience, I wouldn't have
>> more
>> than one installation of PostgreSQL in a production machine. It is
>> potentially problematic.
>>
>
> I agree with you for production environments, but for development, test,
> support (and
> Quoth [EMAIL PROTECTED] ("Mark Woodward"):
>>> Mark Woodward wrote:
As a guy who administers a lot of systems, sometimes over the span of
years, I can not understate the need for "a" place for the admin to
find
what databases are on the machine and where they are located.
>>>
Peter Eisentraut wrote:
Am Mittwoch, 22. Februar 2006 09:06 schrieb Dave Page:
As an example, pgAdmin uses this info to automatically register any
local installations.
Curiously enough, pgAdmin already has a "Service" field in its connection
dialog, but I guess that isn't the same thing. T
Am Mittwoch, 22. Februar 2006 09:06 schrieb Dave Page:
> As an example, pgAdmin uses this info to automatically register any
> local installations.
Curiously enough, pgAdmin already has a "Service" field in its connection
dialog, but I guess that isn't the same thing. The documentation is unclea
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Mark Kirkwood
> Sent: 22 February 2006 01:53
> To: Mark Woodward
> Cc: Tom Lane; Peter Eisentraut; kleptog@svana.org;
> pgsql-hackers@postgresql.org
> Subject:
Christopher Browne wrote:
In the last exciting episode, [EMAIL PROTECTED] (Mark Kirkwood) wrote:
I agree with you for production environments, but for development,
test, support (and pre-sales) machines there are reasonable
requirements for several.
I still have to ask what *specifically* you
In the last exciting episode, [EMAIL PROTECTED] (Mark Kirkwood) wrote:
> Mark Woodward wrote:
>> I'm not sure that I agree. At least in my experience, I wouldn't
>> have more than one installation of PostgreSQL in a production
>> machine. It is potentially problematic.
>
> I agree with you for prod
Mark Woodward wrote:
I'm not sure that I agree. At least in my experience, I wouldn't have more
than one installation of PostgreSQL in a production machine. It is
potentially problematic.
I agree with you for production environments, but for development, test,
support (and pre-sales) machine
Quoth [EMAIL PROTECTED] ("Mark Woodward"):
>> Mark Woodward wrote:
>>> As a guy who administers a lot of systems, sometimes over the span of
>>> years, I can not understate the need for "a" place for the admin to
>>> find
>>> what databases are on the machine and where they are located.
>>>
>>> Yo
> Mark Woodward wrote:
>
>> As a guy who administers a lot of systems, sometimes over the span of
>> years, I can not understate the need for "a" place for the admin to
>> find
>> what databases are on the machine and where they are located.
>>
>> Your assertion that this file would "only works fo
Mark Woodward wrote:
As a guy who administers a lot of systems, sometimes over the span of
years, I can not understate the need for "a" place for the admin to find
what databases are on the machine and where they are located.
Your assertion that this file would "only works for one root-made
in
Mark Woodward wrote:
> OK, maybe pg_service.conf is not the right place for this, and that
> maybe a valid argument, but the mechanics involved would be a great
> asset to the admin. Perhaps pg_servers.conf?
I can see that being useful, in terms of providing pg_ctl with a list of
instances to sta
Tom Lane wrote:
> > I don't mind a mechanism that pg_ctl can start more than one
> > database cluster.
>
> You mean "pg_ctl start -D pgdatalocation", no?
No, I mean pg_ctl start -D location1 -D location2, better yet controlled
by a configuration file.
--
Peter Eisentraut
http://developer.postgr
> "Mark Woodward" <[EMAIL PROTECTED]> writes:
>>> pg_config --sysconfdir
>
>> Hmm, that doesn't show up with pg_config --help.
>
> It's in 8.1.
>
>> One of my difficulties with PostgreSQL is that there is no
>> "standardized"
>> location for where everything is located, i.e. self documenting. If yo
On Tue, 21 Feb 2006, Mark Woodward wrote:
> > Mark Woodward wrote:
> >> The pg_config program needs to display more information, specifically
> >> where the location of pg_service.conf would reside.
> >
> > pg_config --sysconfdir
>
> Hmm, that doesn't show up with pg_config --help.
>
> [EMAIL PRO
"Mark Woodward" <[EMAIL PROTECTED]> writes:
>> pg_config --sysconfdir
> Hmm, that doesn't show up with pg_config --help.
It's in 8.1.
> One of my difficulties with PostgreSQL is that there is no "standardized"
> location for where everything is located, i.e. self documenting. If you
> know that
On Tue, Feb 21, 2006 at 11:14:58AM -0500, Mark Woodward wrote:
> > pg_config --sysconfdir
>
> Hmm, that doesn't show up with pg_config --help.
What version are you using? If I type pg_config without argument it
appears in the list.
> pg_service.conf may currently be considered a "client side" ut
> Mark Woodward wrote:
>> The pg_config program needs to display more information, specifically
>> where the location of pg_service.conf would reside.
>
> pg_config --sysconfdir
Hmm, that doesn't show up with pg_config --help.
[EMAIL PROTECTED]:~$ pg_config --sysconfdir
pg_config: invalid argume
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Mark Woodward wrote:
>> pg_ctl -S service_name start
> I don't mind a mechanism that pg_ctl can start more than one database
> cluster.
You mean "pg_ctl start -D pgdatalocation", no?
regards, tom lane
--
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Mark Woodward wrote:
>> Also, I know I've been harping on this for years (literally), but
>> since the PosgteSQL programs already have the notion that there is
>> some static directory for which to locate files (pg_service.conf),
>> couldn't we also us
On Tue, Feb 21, 2006 at 09:39:16AM -0500, Mark Woodward wrote:
> The pg_config program needs to display more information, specifically
> where the location of pg_service.conf would reside.
AIUI it's supposed to be in SYSCONFDIR which is displayed by pg_config.
I believe you can place the other con
Mark Woodward wrote:
> The pg_config program needs to display more information, specifically
> where the location of pg_service.conf would reside.
pg_config --sysconfdir
> Also, I know I've been harping on this for years (literally), but
> since the PosgteSQL programs already have the notion that
The pg_config program needs to display more information, specifically
where the location of pg_service.conf would reside.
Also, I know I've been harping on this for years (literally), but since
the PosgteSQL programs already have the notion that there is some static
directory for which to locate f
Martijn van Oosterhout wrote:
> I don't see an easy way out. Half the system thinks backslashes are
> special and need expansion, the other half thinks forward slashes are
> option markers. This is really just a variation on the "space in
> filenames" issue in UNIX.
pg_config --pgxs is supposed to
> On 10/14/05, Dave Page wrote:
> > Won't help:
> >
> > Microsoft Windows XP [Version 5.1.2600]
> > (C) Copyright 1985-2001 Microsoft Corp.
> >
> > C:\Documents and Settings\dpage>mkdir c:\foo
> >
> > C:\Documents and Settings\dpage>cd c:/foo
> > The system cannot find the path specified.
> >
> >
> -Original Message-
> From: Christopher A. Watford [mailto:[EMAIL PROTECTED]
> Sent: 14 October 2005 15:58
> To: Dave Page
> Cc: Tom Lane; Martijn van Oosterhout; Thomas Hallgren;
> pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] pg_config --pgxs on Win32
&
On 10/14/05, Dave Page wrote:
> Won't help:
>
> Microsoft Windows XP [Version 5.1.2600]
> (C) Copyright 1985-2001 Microsoft Corp.
>
> C:\Documents and Settings\dpage>mkdir c:\foo
>
> C:\Documents and Settings\dpage>cd c:/foo
> The system cannot find the path specified.
>
> C:\Documents and Setting
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: 13 October 2005 20:41
> To: Dave Page
> Cc: Martijn van Oosterhout; Thomas Hallgren;
> pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] pg_config --pgxs on Win32
>
> "Dave
On Thu, Oct 13, 2005 at 08:36:39PM +0100, Dave Page wrote:
> When we first discussed this I posted a very simple example 'cd /'
> which does absolutely nothing unlike 'cd \' or 'cd \\' which work as
> expected, quite possibly for the reason you suggest. Although the /
> is accepted, I don't believe
"Dave Page" writes:
> When we first discussed this I posted a very simple example 'cd /'
> which does absolutely nothing unlike 'cd \' or 'cd \\' which work as
> expected, quite possibly for the reason you suggest. Although the / is
> accepted, I don't believe it can be called reliable as it obvio
Dave Page wrote:
-Original Message-
From: Martijn van Oosterhout [mailto:[EMAIL PROTECTED]
Sent: Thu 10/13/2005 8:08 PM
To: Tom Lane
Cc: Thomas Hallgren; Dave Page; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] pg_config --pgxs on Win32
Besides, Windows has accepted the
-Original Message-
From: Martijn van Oosterhout [mailto:[EMAIL PROTECTED]
Sent: Thu 10/13/2005 8:08 PM
To: Tom Lane
Cc: Thomas Hallgren; Dave Page; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] pg_config --pgxs on Win32
> Besides, Windows has accepted the forward slash
Dave Page wrote:
We should probably document that pg_config may not work reliably with non-mingw
tools in that case. Microsoft code may or may not do what is expected with
front slashes.
BTW Thomas - I thought you said \\ did work when you were testing options for
me, or was that just msys
On Thu, Oct 13, 2005 at 02:53:09PM -0400, Tom Lane wrote:
> Thomas Hallgren <[EMAIL PROTECTED]> writes:
> > I do have a workaround in place that makes it work for me now. I do
> > $(dir $(subst \\,/,xxx)) and that works fine but given that the targeted
> > platform for pgxs on Win32 is MinGW, per
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> I do have a workaround in place that makes it work for me now. I do
> $(dir $(subst \\,/,xxx)) and that works fine but given that the targeted
> platform for pgxs on Win32 is MinGW, perhaps it should output forward
> slashes anyway.
I've already app
Dave Page wrote:
We should probably document that pg_config may not work reliably with non-mingw
tools in that case. Microsoft code may or may not do what is expected with
front slashes.
BTW Thomas - I thought you said \\ did work when you were testing options for
me, or was that just msys ra
-Original Message-
From: "Tom Lane"<[EMAIL PROTECTED]>
Sent: 13/10/05 18:23:13
To: "Thomas Hallgren"<[EMAIL PROTECTED]>
Cc: "pgsql-hackers@postgresql.org"
Subject: Re: [HACKERS] pg_config --pgxs on Win32
>> The mingw GNU Make is not too
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> Something changed very recently in the output from pg_config --pgxs
> command on Win32. It now outputs double backslash everywhere instead
> of forward slashes. The mingw GNU Make is not too happy about the
> double backslashes.
I said that was a bad i
Something changed very recently in the output from pg_config --pgxs command on Win32. It now
outputs double backslash everywhere instead of forward slashes. The mingw GNU Make is not
too happy about the double backslashes. I do:
export PGXS := $(dir $(shell pg_config --pgxs))
and now it yields
Should that be marked as a beginner TODO?
On Thu, Sep 22, 2005 at 11:04:23PM -0400, Bruce Momjian wrote:
>
> Added to TODO:
>
> * Add options to pg_config to show the share_dir, sysconfdir,
> pkgincludedir, and localedir
>
>
> --
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
>> * Add options to pg_config to show the share_dir, sysconfdir,
>> pkgincludedir, and localedir
> Should that be marked as a beginner TODO?
It could, but I think it's going to get DONE in the next few days as
a necessary step in fixing the pgxs relocata
Added to TODO:
* Add options to pg_config to show the share_dir, sysconfdir,
pkgincludedir, and localedir
---
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Andrew Dunstan wrote:
> >>
Andrew Dunstan wrote:
> Why be so prescriptive?
We're not prescribing anything. You can install your stuff anywhere you
want to, but we're certainly not going to encourage or facilitate that
other software installs files in directories that belong to PostgreSQL,
except where this is specifical
Peter Eisentraut wrote:
Darcy Buskermolen wrote:
We don't need access to that file, but install some sql files into
the share dir, the test for postgresql.conf.sample is there just to
see if the dir looks like a likely candidate to be the dir we are
infact after..
Then my response
Darcy Buskermolen wrote:
> We don't need access to that file, but install some sql files into
> the share dir, the test for postgresql.conf.sample is there just to
> see if the dir looks like a likely candidate to be the dir we are
> infact after..
Then my response is that Slony has absolutely no
1 - 100 of 136 matches
Mail list logo
