On Fri, 2 Aug 2002, Marc G. Fournier wrote:
> Isn't inheritance kinda one of those things that is required in order to
> be consider ourselves ORBDMS, which we do classify our selves as being?
Well, it depends on what you call an ORDBMS. By the standards of
Date and Darwen in _The Third Manifest
On Thu, 1 Aug 2002, Thomas Lockhart wrote:
> > > With FUNC_MAX_ARGS=16:
> > > (average = 28.6 seconds)
> > > With FUNC_MAX_ARGS=32:
> > > (average = 29.15 seconds)
>
> That is almost a 2 percent cost. Shall we challenge someone to get us
> back 2 percent from somewhere before the 7.3 release? Opt
On Fri, 2 Aug 2002, Tom Lane wrote:
> Greg Copeland <[EMAIL PROTECTED]> writes:
> > I seem to find this argument a lot on the list here. For some reason,
> > many of the developers are under the impression that even if code is
> > never touched, it has a very high level of effort to keep it in t
On Fri, 2 Aug 2002, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > 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
> > With FUNC_MAX_ARGS=16:
> > (average = 28.6 seconds)
> > With FUNC_MAX_ARGS=32:
> > (average = 29.15 seconds)
That is almost a 2 percent cost. Shall we challenge someone to get us
back 2 percent from somewhere before the 7.3 release? Optimizing a hot
spot might do it...
"J. R. Nield" <[EMAIL PROTECTED]> writes:
> I am working on a way to do this with a signal, using holdoffs around
> calls into the storage-manager and VFS layers to prevent re-entrant
> calls. The local buffer manager is simple enough that it should be
> possible to flush them from within a signal
...
> Perhaps a more relevant question is why are we cluttering the namespace
> with any such function at all? What's the use case for it? We've
> gotten along fine without one so far, and I don't really think that we
> *ought* to be exposing random bits of internal implementation details
> at t
Bruce Momjian <[EMAIL PROTECTED]> writes:
> 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.
> Artis
Greg Copeland <[EMAIL PROTECTED]> writes:
> I seem to find this argument a lot on the list here. For some reason,
> many of the developers are under the impression that even if code is
> never touched, it has a very high level of effort to keep it in the code
> base. That is, of course, complete
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I can rename backend_pid if people want. I just made it consistent
> with the other functions in that docs area. Comments?
I'd go for pg_backend_pid, I think. It's not an SQL standard function
and certainly never will be, so some sort of prefix seem
"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.
On 1 Aug 2002, Greg Copeland wrote:
> For some reason,
> many of the developers are under the impression that even if code is
> never touched, it has a very high level of effort to keep it in the code
> base. That is, of course, completely untrue.
Where does this "of course" come from? I've bee
Just use $libdir...
Chris
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Ramsey
> Sent: Friday, 2 August 2002 4:01 AM
> To: [EMAIL PROTECTED]
> Subject: [HACKERS] Module Portability
>
>
> All this talk of modularity reminds me of a pet peev
> 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
> functions to provide information to the user -- so there will be
> an increasing need for some kin
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
On Fri, 2 Aug 2002, jtv wrote:
> Looking at it that way, it seems to me that the proper approach is to
> cut out all interfaces that don't talk to the backend themselves--e.g.
> the ones that build on top of libpq, like libpq++ and libpqxx do.
This is what my opinion is ... what I'm setting up r
On Wed, Jul 31, 2002 at 02:08:33PM -0300, Marc G. Fournier wrote:
>
> Who cares? Those that need a C++ interface will know where to find it,
> and will report bugs that they have ... why should it be tested on every
> platform when we *might* only have those on the Linux platform using it?
Wel
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
Bruce Momjian wrote:
> Functions Returning Sets - done?
The basic capability is done, but a number of supporting capabilities
remain. These are the ones I hope to have done for 7.3:
- PL/pgSQL table function support: not started, but I may get help with
this.
- anonymous composite types: pat
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
OK, we need all the interfaces to properly handle schemas within the
next month. However, we don't have psql working properly yet. Once we
get psql working, we can show examples of the changes we made and the
other interfaces can use that as a model.
Is anyone working on schema fixes for psql?
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
It is possible I may be off line intermittently during the next few
weeks. I am moving to a new house _and_ my ISP is switching ADSL
providers at the same time.
This may effect my email account and web pages. I have a secondary mail
host so I will not lose any mail, but I am not sure I can keep
On Thursday 01 August 2002 05:22 pm, Bruce Momjian wrote:
> Lamar Owen wrote:
> > It's already in CPAN. A link to CPAN should suffice, IMHO.
> > I also thought we were discussing trimming the tree; and that was a good
> > feeling.
> Lamar, you said earlier today:
> > And the sooner our very old
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
Thanks. That looks acceptable to me, and a good test.
---
Neil Conway wrote:
> Ok, here are some crude benchmarks to attempt to measure the effect of
> changing FUNC_MAX_ARGS. The benchmark script executed:
>
> CREATE FUN
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 3
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 che
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
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
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
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
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
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, 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
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
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
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
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() ).
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
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
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;
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
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
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
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
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
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
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
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
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
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 <[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
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
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
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.
> > >
> > > $
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
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
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
> > $
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:
> "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
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
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)
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
UNSUSCRIBE
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
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
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
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:
> 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
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, 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
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, 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
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
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
"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
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
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
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.
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 ...
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
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
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 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.
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
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:
>
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
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.
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
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
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, 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
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, 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
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
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
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
>
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
> 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
1 - 100 of 122 matches
Mail list logo
