On Thu, 2002-08-01 at 02:05, Bruce Momjian wrote:
> Marc G. Fournier wrote:
> > On Wed, 31 Jul 2002, Neil Conway wrote:
> >
> > > On Wed, Jul 31, 2002 at 02:01:43AM -0300, Marc G. Fournier wrote:
> > > > add in 'fix pg_hba.conf / password issues' to that too :)
> > >
> > > I doubt that will make
On Thu, 2002-08-01 at 06:48, Marc G. Fournier wrote:
> On Wed, 31 Jul 2002, Bruce Momjian wrote:
>
> > One idea I had was to look for a colon in the username, and if I see
> > one, I assume everything after the colon is a password. Would that work
> > for you?
>
> That would definitely work ...
> -Original Message-
> From: Iavor Raytchev [mailto:[EMAIL PROTECTED]]
> Sent: 31 July 2002 22:12
> To: pgsql-hackers
> Cc: pgaccess - developers
> Subject: Re: [HACKERS] Open 7.3 items
>
>
>
> > > psql is very definitely not ready, nor is pgaccess.
>
> I could not really trace who
Bruce Momjian dijo:
> Here are the open items for 7.3. We have one more month to address them
> before beta.
> CLUSTER - ready?
I'm just back. I'll have a look at the problem with the patch and
resubmit.
--
Alvaro Herrera ()
"Es filosofo el que disfruta con los enigmas" (G. Coli)
---
> > > NAMEDATALEN - disk/performance penalty for increase, 64, 128?
> > > FUNC_MAX_ARGS - disk/performance penalty for increase, 24, 32?
> >
> > At the moment I don't see a lot of solid evidence that increasing
> > NAMEDATALEN has any performance penalty. Someone reported about
> > a 10% slowdo
Le Mercredi 31 Juillet 2002 05:50, Bruce Momjian a écrit :
> Here are the open items for 7.3. We have one more month to address them
> before beta.
Is CREATE OR REPLACE VIEW on the list?
---(end of broadcast)---
TIP 3: if posting/reading through U
On Tue, Jul 30, 2002 at 09:48:42PM -0400, Bruce Momjian wrote:
>
> OK, renamed to backend_pid() to match the libpq name. I was unsure
> about merging it into the stats stuff myself.
>
> setest=> select backend_pid();
>backend_pid
> -
> 12996
>
> But the message I was replying to was a similar union query, and I was
> thinking that that person might be having a similar initial intuitive
> reaction, "well, it looks kinda the same." I just wanted to note that
> you need to check this stuff with explain, rather than
> blindly assuming
> y
On Thu, 1 Aug 2002, Zeugswetter Andreas SB SD wrote:
> I had a "union all" view, which is actually a quite different animal than
> a "union" view which needs to eliminate duplicates before further processing.
I had the same problem with UNION ALL.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81
On Thu, 2002-08-01 at 12:29, Curt Sampson wrote:
> On Thu, 1 Aug 2002, Zeugswetter Andreas SB SD wrote:
>
> > I had a "union all" view, which is actually a quite different animal than
> > a "union" view which needs to eliminate duplicates before further processing.
>
> I had the same problem wit
... is once more 'normal' ...
there are three modules right now setup:
earthdistance
libpqxx
pgsql-server
pgsql combines all three of the above to transparently give the equivalent
of the whole distribution from its component parts ...
---(end of broadcast)-
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
>> I realize that Marc wasn't proposing splitting off any
>> server-side code, but I still want to tread carefully about breaking
>> up the codebase.
> Okay, well, the way I'm working it through right now, I'm doing it in such
> a way that unless you
On Thu, 1 Aug 2002, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> >> I realize that Marc wasn't proposing splitting off any
> >> server-side code, but I still want to tread carefully about breaking
> >> up the codebase.
>
> > Okay, well, the way I'm working it through right n
Hannu Krosing <[EMAIL PROTECTED]> writes:
> This name mangling should be done at connect time and kept out of
> database, where each users name should always be fully resolved
> ([EMAIL PROTECTED]).
I really like Hannu's approach to this. It seems to solve Marc's
problem with a very simple, eas
On 1 Aug 2002, Hannu Krosing wrote:
> On Thu, 2002-08-01 at 12:29, Curt Sampson wrote:
> > On Thu, 1 Aug 2002, Zeugswetter Andreas SB SD wrote:
> >
> > > I had a "union all" view, which is actually a quite different animal than
> > > a "union" view which needs to eliminate duplicates before furth
On Thu, Aug 01, 2002 at 12:01:52PM +0200, Karel Zak wrote:
> Is there some common convention of names?
No, there isn't (for example, pg_stat_backend_id() versus
current_schema() -- or pg_get_viewdef() versus obj_description() ).
Now that we have table functions, we might be using more built-in
f
On Thu, 2002-08-01 at 10:44, Neil Conway wrote:
> On Thu, Aug 01, 2002 at 12:01:52PM +0200, Karel Zak wrote:
> > Is there some common convention of names?
> functions. However, establishing a naming convention without
> breaking backwards compatibility might be tricky.
Supporting both names for
On Thu, 1 Aug 2002, Stephan Szabo wrote:
> On 1 Aug 2002, Hannu Krosing wrote:
>
> > On Thu, 2002-08-01 at 12:29, Curt Sampson wrote:
> > > On Thu, 1 Aug 2002, Zeugswetter Andreas SB SD wrote:
> > >
> > > > I had a "union all" view, which is actually a quite different animal than
> > > > a "unio
On Thu, Aug 01, 2002 at 10:44:23AM -0400, Neil Conway wrote:
> On Thu, Aug 01, 2002 at 12:01:52PM +0200, Karel Zak wrote:
> > Is there some common convention of names?
>
> No, there isn't (for example, pg_stat_backend_id() versus
I know -- for this I asked. IMHO for large project like PostgreS
On Wednesday 31 July 2002 09:38 pm, Marc G. Fournier wrote:
> Okay ... since this is pretty much going to be 'one camp for, one camp
> against' without anything to really back up either camps perspectives /
> arguments, I did some research on CVS in order to find a nice, effective
> middle ground
> And the sooner our very old perl client goes away, the better I
> like it. It
> is a good client, don't get me wrong: but DBD:Pg is the standard now.
>
This may sound like a dumb question, but DBD::Pg == DBI right ? not pg.pm
I code perl about 25 hours a week, and DBI has never failed me y
On Thursday 01 August 2002 12:05 pm, Jeff MacDonald wrote:
> > And the sooner our very old perl client goes away, the better I
> > like it. It
> > is a good client, don't get me wrong: but DBD:Pg is the standard now.
> This may sound like a dumb question, but DBD::Pg == DBI right ? not pg.pm
Ri
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> ... is once more 'normal' ...
Uh, it's completely broken as far as I can tell.
$ pwd
/home/postgres/pgsql/src/bin/pg_dump
$ cvs status
cvs server: Examining .
cvs server: failed to create lock directory for `/cvsroot/pgsql/src/bin/pg_dump'
(/cvsr
On Wed, Jul 31, 2002 at 11:20:35PM -0400, Bruce Momjian wrote:
>
> I am wondering why we even want to specify the WAL location anywhere
> except as a flag to initdb. If you specify a location at initdb time,
> it creates the /xlog directory, then symlinks it into /data.
I thought the whole poin
On Thu, 1 Aug 2002, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > ... is once more 'normal' ...
>
> Uh, it's completely broken as far as I can tell.
>
> $ pwd
> /home/postgres/pgsql/src/bin/pg_dump
> $ cvs status
> cvs server: Examining .
> cvs server: failed to create lock
On Thu, 1 Aug 2002, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > ... is once more 'normal' ...
>
> Uh, it's completely broken as far as I can tell.
>
> $ pwd
> /home/postgres/pgsql/src/bin/pg_dump
> $ cvs status
> cvs server: Examining .
> cvs server: failed to create lock
On Thu, 2002-08-01 at 15:33, Vince Vielhaber wrote:
> On Thu, 1 Aug 2002, Tom Lane wrote:
>
> > "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > > ... is once more 'normal' ...
> >
> > Uh, it's completely broken as far as I can tell.
> >
> > $ pwd
> > /home/postgres/pgsql/src/bin/pg_dump
> > $
Rod Taylor <[EMAIL PROTECTED]> writes:
> Also, http://developer.postgresql.org/cvsweb.cgi/pgsql/ isn't working.
>>
>> What'r you typin about? It works fine. Ok, ok.. It does *NOW*. :)
> Well, of course that specific URL doesn't work because it's actually
> pgsql-server.
Well, it did work be
All this talk of modularity reminds me of a pet peeve: doing
dump/restore upgrades when your databases include extension functions is
highly clunky, because extension functions include the fully qualified
path to the linking library. So, for example
create function geometry_in(opaque)
RET
On 1 Aug 2002, Rod Taylor wrote:
> On Thu, 2002-08-01 at 15:33, Vince Vielhaber wrote:
> > On Thu, 1 Aug 2002, Tom Lane wrote:
> >
> > > "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > > > ... is once more 'normal' ...
> > >
> > > Uh, it's completely broken as far as I can tell.
> > >
> > > $
On Thu, 1 Aug 2002, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > Also, http://developer.postgresql.org/cvsweb.cgi/pgsql/ isn't working.
> >>
> >> What'r you typin about? It works fine. Ok, ok.. It does *NOW*. :)
>
> > Well, of course that specific URL doesn't work because it's
Seems the CVS server is not working correctly. I just deleted my CVS
tree and did a fresh checkout of the pgsql module. Everything seemingly
went well. After the check out completed, I did:
[gcope@mouse pgsql]$ ./configure --with-tcl --with-java --with-python
--with-perl
checking build system
Someone said earlier cvsup would have problems but the anonymous cvs would work
fine.
Well I've just had a weirdness reconfiguring and rebuilding my few weeks old
7.3dev tree and so deleted it and tried using the anoncvs to get pgsql. Running
configure gives me the error:
./configure: ./src/t
Looks like I replied to the wrong thread...here's a repeat...
Seems the CVS server is not working correctly. I just deleted my CVS
tree and did a fresh checkout of the pgsql module. Everything seemingly
went well. After the check out completed, I did:
[gcope@mouse pgsql]$ ./configure --with-t
Should be fixed now ... I found a rsync.core file, so it looks like the
changes may have been more extensive then rsync could handle ... just ran
it manually (or, rather, am running as I type this), so by the time you
receive, a checkout should grab the right structures ...
Let me know if it wor
Stephan Szabo <[EMAIL PROTECTED]> writes:
> For union, queries that want to do something like use a temporary
> sequence to act sort of like rownum and do row limiting. Admittedly
> that's already pretty much unspecified behavior, but it does change
> the behavior in the place of duplicate remova
On Thu, 1 Aug 2002, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > For union, queries that want to do something like use a temporary
> > sequence to act sort of like rownum and do row limiting. Admittedly
> > that's already pretty much unspecified behavior, but it does change
>
Jean-Michel POURE wrote:
> Le Mercredi 31 Juillet 2002 05:50, Bruce Momjian a ?crit :
> > Here are the open items for 7.3. We have one more month to address them
> > before beta.
>
> Is CREATE OR REPLACE VIEW on the list?
No. It can still be done, but no one is working on it.
--
Bruce Momj
Yes, it's compiling now...thanks.
Greg
On Thu, 2002-08-01 at 18:31, Marc G. Fournier wrote:
>
> Should be fixed now ... I found a rsync.core file, so it looks like the
> changes may have been more extensive then rsync could handle ... just ran
> it manually (or, rather, am running as I type thi
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
>> Well, it did work before, and I'd really like it to work again. I do
>> not want to think about how Marc's broken apart the distribution when
>> I'm looking at my local tree, and I don't want to think about it when
>> I'm looking at cvsweb either.
Stephan Szabo <[EMAIL PROTECTED]> writes:
> Actually I think in except you may only push down to the left, since in
> this case you know that any duplicate from the right will not be
> returned (since there must be none). So, you can't potentially drop
> a row from the right side that may have be
On Thu, Aug 01, 2002 at 12:56:11AM -0300, Marc G. Fournier wrote:
> I've just updated the README.cvsup file in order to reflect the changes,
> to provide a sample of how to download the whole thing, as well as
> instructions on how to do "just" a particular module:
I'm using the following cvsup f
On Wednesday 31 July 2002 04:56 pm, Bruce Momjian wrote:
> Thomas Lockhart wrote:
>> Tom Lane wrote:
> > > I agree that if we could quickly come to a resolution about how this
> > > ought to work, there's plenty of time to go off and implement it.
> > afaict someone else volunteered to do the wor
On Thu, 2002-08-01 at 18:02, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > For union, queries that want to do something like use a temporary
> > sequence to act sort of like rownum and do row limiting. Admittedly
> > that's already pretty much unspecified behavior, but it does c
Try now ... the download isn't going to work right though, as CVSup
doesn't honor the modules file in CVSROOT which defines how 'pgsql' is
*supposed* to work ... I'm going to work on this later tonight and see if
I can find something in the docs that will allow it to work properly, but
right now,
On Thu, 1 Aug 2002, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > If we assume two collations one case sensitive one not with the
> > except in the non-sensitive and the where in the sensitive and
> > a left with 'A' and right with 'a', it'd be incorrect to push a
> > case sens
Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > This name mangling should be done at connect time and kept out of
> > database, where each users name should always be fully resolved
> > ([EMAIL PROTECTED]).
>
> I really like Hannu's approach to this. It seems to solve Marc's
> p
Lamar Owen wrote:
> And the sooner our very old perl client goes away, the better I like it. It
> is a good client, don't get me wrong: but DBD:Pg is the standard now.
I have been in contact with Edmund about moving DBD into our CVS and
updating CPAN ourselves. Should have a final answer soon.
Marc G. Fournier wrote:
> So, from the 'client side', y'all will still see "everything as one big
> package", while from the 'server side', I'll have the seperate modules
> taht can be packaged independently ...
Marc, how are you dealing with libpq's access to the server include
files?
--
Bru
Added to TODO:
* Consistently name server-side internal functions
---
Karel Zak wrote:
> On Thu, Aug 01, 2002 at 10:44:23AM -0400, Neil Conway wrote:
> > On Thu, Aug 01, 2002 at 12:01:52PM +0200, Karel Zak wrote:
>
I can rename backend_pid if people want. I just made it consistent
with the other functions in that docs area. Comments?
---
Karel Zak wrote:
> On Thu, Aug 01, 2002 at 10:44:23AM -0400, Neil Conway wrote:
> > On Thu, Aug
On Thu, 2002-08-01 at 16:17, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > This name mangling should be done at connect time and kept out of
> > database, where each users name should always be fully resolved
> > ([EMAIL PROTECTED]).
>
> I really like Hannu's approach to this.
Marc G. Fournier wrote:
>
> ... is once more 'normal' ...
>
> there are three modules right now setup:
>
> earthdistance
> libpqxx
> pgsql-server
>
> pgsql combines all three of the above to transparently give the equivalent
> of the whole distribution from its component parts ...
Marc, I hav
On Thu, 2002-08-01 at 19:41, Bruce Momjian wrote:
>
> Added to TODO:
>
> * Consistently name server-side internal functions
I'd suggest:
* Make up rules for consistently naming server-side internal functions
* Consistently name _new_ server-side internal functions
* make a plan f
On Thu, 1 Aug 2002, Bruce Momjian wrote:
> Marc G. Fournier wrote:
> > So, from the 'client side', y'all will still see "everything as one big
> > package", while from the 'server side', I'll have the seperate modules
> > taht can be packaged independently ...
>
> Marc, how are you dealing with l
Marc G. Fournier wrote:
> On Thu, 1 Aug 2002, Bruce Momjian wrote:
>
> > Marc G. Fournier wrote:
> > > So, from the 'client side', y'all will still see "everything as one big
> > > package", while from the 'server side', I'll have the seperate modules
> > > taht can be packaged independently ...
Bruce Momjian wrote:
> Lamar Owen wrote:
> > And the sooner our very old perl client goes away, the better I like it. It
> > is a good client, don't get me wrong: but DBD:Pg is the standard now.
>
> I have been in contact with Edmund about moving DBD into our CVS and
> updating CPAN ourselves.
On Tue, 2002-07-30 at 14:54, Hannu Krosing wrote:
> On Tue, 2002-07-30 at 16:00, Curt Sampson wrote:
> > On 30 Jul 2002, Hannu Krosing wrote:
> >
> > > On Tue, 2002-07-30 at 14:51, Adrian 'Dagurashibanipal' von Bidder wrote:
> > >
> > > > Bruce Momjian:
> > > > > It causes too much complexity in
I have discussed the idea of contributing our Win32 work to the
PostgreSQL project with management.
We have also converted all of the utilities (initdb, psql, pg_dump,
pg_restore, pg_id, pg_passwd, etc.)
Management is (rightfully) concerned about recouping the many thousands
of dollars invested
Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > ... is once more 'normal' ...
>
> Uh, it's completely broken as far as I can tell.
>
> $ pwd
> /home/postgres/pgsql/src/bin/pg_dump
> $ cvs status
> cvs server: Examining .
> cvs server: failed to create lock directory for `/cv
Do we have any way to disable foreign key constraints? If not, I would
like to add it to TODO. I was asked for this feature several times at
O'Reilly.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is
On Thu, 1 Aug 2002, Bruce Momjian wrote:
> Bruce Momjian wrote:
> > Lamar Owen wrote:
> > > And the sooner our very old perl client goes away, the better I like it. It
> > > is a good client, don't get me wrong: but DBD:Pg is the standard now.
> >
> > I have been in contact with Edmund about mov
Oleg Bartunov wrote:
> On Thu, 1 Aug 2002, Bruce Momjian wrote:
>
> > Bruce Momjian wrote:
> > > Lamar Owen wrote:
> > > > And the sooner our very old perl client goes away, the better I like it. It
> > > > is a good client, don't get me wrong: but DBD:Pg is the standard now.
> > >
> > > I have
On Thu, 1 Aug 2002, Dann Corbit wrote:
> I have discussed the idea of contributing our Win32 work to the
> PostgreSQL project with management.
>
> We have also converted all of the utilities (initdb, psql, pg_dump,
> pg_restore, pg_id, pg_passwd, etc.)
>
> Management is (rightfully) concerned abo
Stephan Szabo <[EMAIL PROTECTED]> writes:
> So if T1 has a #dups>0 and T2 has a #dups>0 we should get
> no rows, but what if T1' (with the clause) has a #dups>0 but
> T2' has a #dups=0?
Um, you're right --- pushing down into the right-hand side would reduce
N, thereby possibly *increasing* the nu
On Thu, 1 Aug 2002, Bruce Momjian wrote:
> Marc G. Fournier wrote:
> > On Thu, 1 Aug 2002, Bruce Momjian wrote:
> >
> > > Marc G. Fournier wrote:
> > > > So, from the 'client side', y'all will still see "everything as one big
> > > > package", while from the 'server side', I'll have the seperate
On Thu, Aug 01, 2002 at 05:09:52PM +0200, Karel Zak wrote:
> I know -- for this I asked. IMHO for large project like PostgreSQL
> it's important. It's not good if there is possible speculate about
> name of new function. It must be unmistakable -- for this is needful
> make some convension. If
On Thu, 1 Aug 2002, Bruce Momjian wrote:
> Bruce Momjian wrote:
> > Lamar Owen wrote:
> > > And the sooner our very old perl client goes away, the better I like it. It
> > > is a good client, don't get me wrong: but DBD:Pg is the standard now.
> >
> > I have been in contact with Edmund about mov
Ummm ... stupid question, but can we even bring this into the 'core'?
You may distribute under the terms of either the GNU General Public
License or the Artistic License, as specified in the Perl README file.
On Thu, 1 Aug 2002, Oleg Bartunov wrote:
> On Thu, 1 Aug 2002, Bruce Momjian
UNSUSCRIBE
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Marc G. Fournier wrote:
>
> Ummm ... stupid question, but can we even bring this into the 'core'?
>
>You may distribute under the terms of either the GNU General Public
>License or the Artistic License, as specified in the Perl README file.
Artistic License is fine, I think.
--
Bruc
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Do we have any way to disable foreign key constraints?
You can drop and re-add the constraint relatively painlessly in 7.3.
Formerly it took hacking on pg_trigger.
regards, tom lane
---(end of broadcast)
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Do we have any way to disable foreign key constraints?
>
> You can drop and re-add the constraint relatively painlessly in 7.3.
> Formerly it took hacking on pg_trigger.
OK, let's see if it comes up after 7.3.
--
Bruce Momjian
On Thursday 01 August 2002 02:21 pm, Bruce Momjian wrote:
> Bruce Momjian wrote:
> > Lamar Owen wrote:
> > > And the sooner our very old perl client goes away, the better I like
> > > it. It is a good client, don't get me wrong: but DBD:Pg is the
> > > standard now.
> > I have been in contact wi
On Thu, 1 Aug 2002, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > So if T1 has a #dups>0 and T2 has a #dups>0 we should get
> > no rows, but what if T1' (with the clause) has a #dups>0 but
> > T2' has a #dups=0?
>
> Um, you're right --- pushing down into the right-hand side wou
Neil Conway writes:
> On Thu, Aug 01, 2002 at 12:01:52PM +0200, Karel Zak wrote:
> > Is there some common convention of names?
>
> No, there isn't (for example, pg_stat_backend_id() versus
> current_schema() -- or pg_get_viewdef() versus obj_description() ).
The "pg_" naming scheme is obsolete
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> (Actually, what I'd prefer it do is try first for username, and
>> then username@databasename if plain username isn't found.)
> Yes, that would be very easy to do _except_ for pg_hba.conf which does a
> first-match for username. We could get into trou
Contrib modules does have such possibility.
For example:
CREATE FUNCTION ltree_in(opaque)
RETURNS opaque
AS 'MODULE_PATHNAME'
LANGUAGE 'c' with (isstrict);
Oleg
On Thu, 1 Aug 2002, Paul Ramsey wrote:
> All this talk of modularity reminds me of a pet peeve: doing
> dump/restore upgrades
Bruce Momjian writes:
> OK, I have attached a patch for testing. Sample output is:
>
> $ sql -U guest test
> psql: FATAL: user "test.guest" does not exist
> $ createuser test.guest
I will object to any scheme that makes any characters in the user name
magic. Two reasons: Fi
Marc G. Fournier writes:
> Next, unless Peter knows how to do it already, I've gotta learn to make
> configure more intelligent, so that for all intents, the "pieces" look
> like one package when building, not just when coding ...
It is possible, but it's not going to work.
There is a lot of in
Tom Lane writes:
> We've had several proposals in this thread for complicated extensions
> to the user naming mechanism. I think that's overdesigning the feature,
> because we have *no* examples of real-world need for such things except
> for Marc's situation. Let's keep it simple until we see
Lamar Owen writes:
> > allow specification of configuration files in a different directory
> I am going to review the previous thread and attempt to distill what can be
> done. I will then post a summary of what I found, with potential commentary.
> If a consensus is reached, I'd like to se
Correct me if I am wrong (I often am) but isn't MODULE_PATHNAME replaced
by the fully qualified module path during the build process? I mean, the
source code is movable, but a running installed system, with real data,
is not movable, because MODULE_PATHNAME gets mapped to
/usr/local/mypgsql/lib/bl
Marc G. Fournier writes:
> I haven't touched libpq yet ... I'm talking with the libpqxx guys right
> now concerning getting the standalone libpqxx to work, and will be working
> on figuring out how to get the 'master configure' to make use of the
> standalone configure once that is fixed ... I wa
Paul Ramsey writes:
> It would be nice if pgsql had a 'default library location'
Sure. That's why it was implemented in 7.2.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://a
Bruce Momjian writes:
> Artistic License is fine, I think.
The Artistic License doesn't even qualify as Free Software as far as the
FSF is concerned.
More generally, it is a different license, and that is a problem.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of
Bruce Momjian writes:
> OK, I got the go-ahead from Edmund. We will have DBD:pg in the 7.3
> tarball. I will add it to CVS today or tomorrow.
Please, no more Perl modules in our CVS! The ones we have are already
messy enough to build.
I thought we were talking about trimming the source t
On Thursday 01 August 2002 04:37 pm, Peter Eisentraut wrote:
> I thought we were talking about trimming the source tree, not adding more.
> Why not put it on gborg or somewhere else?
It's already in CPAN. A link to CPAN should suffice, IMHO.
I also thought we were discussing trimming the tree;
On Thursday 01 August 2002 04:06 pm, Peter Eisentraut wrote:
> Another issue, which becomes even more problematic if you factor in the
> WAL file location discussion, is that if we drive the location of the data
> from the configuration file instead of vice versa, we need to have initdb
> smart en
Color me embarrased. /
Peter Eisentraut wrote:
>
> Paul Ramsey writes:
>
> > It would be nice if pgsql had a 'default library location'
>
> Sure. That's why it was implemented in 7.2.
>
> --
> Peter Eisentraut [EMAIL PROTECTED]
--
__
/
| Paul Ramsey
| Refractions Re
Peter Eisentraut wrote:
> Neil Conway writes:
>
> > On Thu, Aug 01, 2002 at 12:01:52PM +0200, Karel Zak wrote:
> > > Is there some common convention of names?
> >
> > No, there isn't (for example, pg_stat_backend_id() versus
> > current_schema() -- or pg_get_viewdef() versus obj_description() ).
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> (Actually, what I'd prefer it do is try first for username, and
> >> then username@databasename if plain username isn't found.)
>
> > Yes, that would be very easy to do _except_ for pg_hba.conf which does a
> > first-match for usern
On Thu, 1 Aug 2002, Lamar Owen wrote:
> On Thursday 01 August 2002 04:37 pm, Peter Eisentraut wrote:
> > I thought we were talking about trimming the source tree, not adding more.
> > Why not put it on gborg or somewhere else?
>
> It's already in CPAN. A link to CPAN should suffice, IMHO.
>
> I
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > OK, I have attached a patch for testing. Sample output is:
> >
> > $ sql -U guest test
> > psql: FATAL: user "test.guest" does not exist
> > $ createuser test.guest
>
> I will object to any scheme that makes any characters in th
Peter Eisentraut wrote:
> Tom Lane writes:
>
> > We've had several proposals in this thread for complicated extensions
> > to the user naming mechanism. I think that's overdesigning the feature,
> > because we have *no* examples of real-world need for such things except
> > for Marc's situation.
On Thu, 1 Aug 2002, Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > Bruce Momjian writes:
> >
> > > OK, I have attached a patch for testing. Sample output is:
> > >
> > > $ sql -U guest test
> > > psql: FATAL: user "test.guest" does not exist
> > > $ createuser test.guest
> >
> > I wil
J.R needs comments on this. PITR has problems because local relations
aren't logged to WAL. Suggestions?
---
J. R. Nield wrote:
> As per earlier discussion, I'm working on the hot backup issues as part
> of the PITR suppo
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > Artistic License is fine, I think.
>
> The Artistic License doesn't even qualify as Free Software as far as the
> FSF is concerned.
>
> More generally, it is a different license, and that is a problem.
Well, our ODBC is LGPL. I wonder if E
Marc G. Fournier wrote:
> > > I will object to any scheme that makes any characters in the user name
> > > magic. Two reasons: First, do it right, make a separate column.
> > > Second, several tools use URI syntax to specify data sources. This will
> > > break any feature that relies on being a
Lamar Owen wrote:
> On Thursday 01 August 2002 04:37 pm, Peter Eisentraut wrote:
> > I thought we were talking about trimming the source tree, not adding more.
> > Why not put it on gborg or somewhere else?
>
> It's already in CPAN. A link to CPAN should suffice, IMHO.
>
> I also thought we wer
1 - 100 of 122 matches
Mail list logo
