On Thu, 1 Aug 2002, Tom Lane wrote:
Thomas Lockhart [EMAIL PROTECTED] writes:
Until we have folks who are excited enough about it to plan it out and
do the work, piecemeal rejection of components is not leading to a more
solid product.
I'm lukewarm about whether to actually do the split
On Wed, 31 Jul 2002, Thomas Lockhart wrote:
...
*Eventually*, a simple checkout of 'pgsql' should result in a server
only distribution that we can pull bits and pieces into transparently ...
I'm still not quite sure where this is headed or why, but if nothing
else pgsql could and should
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 7.3 -- the
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 ... but I
-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 said this.
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 (alvherre[a]atentus.com)
Es filosofo el que disfruta con los enigmas
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% slowdown on pgbench
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
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
(1
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
you know
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 90
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 with UNION
... 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
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 go mucking
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 now, I'm doing it
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, easily
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 further processing.
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
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 a
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 union view which needs
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 PostgreSQL
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 yet.
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
Right.
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 point
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 directory for
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 directory for
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
$ cvs status
cvs
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 before,
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)
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.
$ pwd
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 actually
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
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:
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
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
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 removal.
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
the
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 Momjian
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 this),
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.
You
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 been a
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 file,
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 work. There
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 change
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
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 sensitive
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
problem with
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?
--
Bruce
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. It seems
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 have to ask,
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 for
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 libpq's
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 ...
Marc, how
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. Should
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 other parts of the
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
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
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 moving DBD into
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 been in contact with
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 about
Stephan Szabo [EMAIL PROTECTED] writes:
So if T1 has a #dups0 and T2 has a #dups0 we should get
no rows, but what if T1' (with the clause) has a #dups0 but
T2' has a #dups=0?
Um, you're right --- pushing down into the right-hand side would reduce
N, thereby possibly *increasing* the number of
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 modules
taht
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 moving DBD into
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
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.
--
Bruce
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
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 with Edmund
On Thu, 1 Aug 2002, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
So if T1 has a #dups0 and T2 has a #dups0 we should get
no rows, but what if T1' (with the clause) has a #dups0 but
T2' has a #dups=0?
Um, you're right --- pushing down into the right-hand side would reduce
N,
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 because
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 trouble
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: First,
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
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 see
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
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 want
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?
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
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
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 Research
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() ).
The pg_
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 username. We
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. Let's
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 will object to any scheme
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
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 Edmund
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 able to put
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 were
On Thu, 2002-08-01 at 17:14, Bruce Momjian wrote:
J.R needs comments on this. PITR has problems because local relations
aren't logged to WAL. Suggestions?
I'm sorry if it wasn't clear. The issue is not that local relations
aren't logged to WAL, they are. The issue is that you can't
Ok, here are some crude benchmarks to attempt to measure the effect of
changing FUNC_MAX_ARGS. The benchmark script executed:
CREATE FUNCTION test_func(int, int, int, int, int, int, int, int)
RETURNS INTEGER AS 'SELECT $1 + $2 + $3 + $4 + $5 + $6 + $7 + $8'
LANGUAGE 'sql' VOLATILE;
Followed by
1 - 100 of 115 matches
Mail list logo
