Re: [HACKERS] Remove implicit unique index creation on SERIAL columns?
Tom Lane wrote: > Joe Conway <[EMAIL PROTECTED]> writes: >>I agree 100%. If you want an index, unique constraint, or primary key on >>a SERIAL, I think you should explicitly add it. SERIAL should give me a >>column that automatically increments -- no more, no less. > > Hmm, do you also want to eliminate the implicit NOT NULL constraint? > > I think that efficiency and orthogonality are adequate reasons for > dissociating UNIQUE from SERIAL. The efficiency argument is pretty > weak in the case of the NOT NULL part, though, so maybe backwards > compatibility should win out there. To be honest I wasn't thinking about NOT NULL. I'd agree with leaving that in place. Maybe I should restate my comment above: SERIAL should give me a column that automatically increments -- no more, no less -- and it should not allow me to override the value that it gives. Hence an implicit NOT NULL, but also an implicit rejection of a manual insert/update of that field (how hard would this be to do?). I know this causes problems for dumped and reloaded data. In MSSQL this is gotten around by allowing the properties of the data type to be altered, e.g. in MSSQL you can turn the IDENTITY property on or off (in fact, I just checked and MSSQL won't allow you to turn on IDENTITY for a column unless you turn off ALLOW NULLS). You can also specify an exception to the rule when running BCP (the bulk loader command line program). The reason I think this behavior is good, is that it helps prevent toe loss from stray bullets. E.g. you manually add a row where you've specified some value that has not yet been reached by the sequence -- then when someday the sequence reaches said value, your insert fails on a duplicate primary key insertion attempt. If you really need to be able to insert or update a field with an explicit value *sometimes* (and you really know what you're doing), then use a plain sequence and a default, not a SERIAL. Anyway, just my thoughts. Joe ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] cvs-tip broken
Rod Taylor <[EMAIL PROTECTED]> writes: > Hmm.. whelp, the file in question on FreeBSD is sys/time.h (attached > earlier) so this won't fix it. Added #include . We seem to use this unconditionally in many other files, so I don't see a reason not to include it here. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] cvs-tip broken
On Sat, 2002-08-17 at 22:44, Bruce Momjian wrote: > > I think I added time.h and sys/types.h. That should do it for you. Hmm.. whelp, the file in question on FreeBSD is sys/time.h (attached earlier) so this won't fix it. > --- > > Rod Taylor wrote: > > On Sat, 2002-08-17 at 22:08, Tom Lane wrote: > > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > > > I am not seeing the failure here on BSD/OS. I just fixed the > > > > libpq-int.h problem. Please update to cvs current and let me know what > > > > you see. > > > > > > FWIW, libpq seems to build fine here (HPUX 10.20) both before and after > > > your latest commit. Rod should probably mention what platform he's > > > using, and where it defines struct timeval... > > > > I still have to wait another 30 minutes before I can update to the > > latest revision, but here's what's needed: > > > > > > bash-2.05b$ uname -a > > FreeBSD jester 4.6-RELEASE FreeBSD 4.6-RELEASE #8: Fri Jul 19 23:45:16 > > EDT 2002 root@jester:/usr/obj/usr/src/sys/JESTER i386 > > > > > > [ Attachment, skipping... ] > > -- > Bruce Momjian| http://candle.pha.pa.us > [EMAIL PROTECTED] | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup.| Newtown Square, Pennsylvania 19073 > > ---(end of broadcast)--- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to [EMAIL PROTECTED] so that your > message can get through to the mailing list cleanly > ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Open 7.3 items
As you can see, the open items list is greatly shrunk. We have two weeks to go and most of these seems do-able, except for point-in-time recovery, which may not make it. I haven't heard anything recently on it. Would someone put together a porting document for schema changes and drop column changes? --- P O S T G R E S Q L 7 . 3 O P E NI T E M S Current at ftp://candle.pha.pa.us/pub/postgresql/open_items. Source Code Changes --- Point-in-time recovery - status? (J.R., Richard) Schema handling - ready? interfaces? client apps? Drop column handling - ready for all clients, apps? ecpg and bison issues - solved? (Michael) have pg_dumpall dump out db privilege and per-user/db settings fix implicit type coercions that are worse Prepared statements - to be reviewed (Tom) improve macros in new tuple header code (Tom) integrate or move to gborg libpqxx, Pg:DBD Allow PL/PgSQL functions to return sets (Neil) Allow easy display of usernames in a group (pg_hba.conf uses groups now) fix BeOS and QNX4 ports Documentation Changes - Mention foreign keys and SERIAL dependencies will not be in 7.2 loaded tables Document need to add permissions to loaded functions and languages -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Open 7.3 items
OK, applied, with that change. --- Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > OK, here is the patch with the suggested changes. I am sending the > > patch to hackers because there has been so much interest in this. > > One minor gripe: > > > + /* If user@, it is a global user, remove '@' */ > > + if (strchr(port->user, '@') == port->user + strlen(port->user)-1) > > This code is correct, but it tempts someone to replace the strchr() > with a single-character check on the last character of the string. > Which would introduce the security hole we discussed before. The > code is okay, but *please* improve the comment to point out that you > are also excluding the case where there are @'s to the left of the > last character. > > regards, tom lane > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] compile warnings in CVS
I said: > Another alternative is > char *fmt = "%c"; > ... > strftime(..., fmt, ...); > which I think will probably defeat gcc's check (haven't tried it > though). I tried this, and it did shut up the warning in my local copy of gcc. So I committed it. > Does anyone want to argue that %c is actually a bad choice? This is still open to debate if anyone wants to make the case... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] cvs-tip broken
I think I added time.h and sys/types.h. That should do it for you. --- Rod Taylor wrote: > On Sat, 2002-08-17 at 22:08, Tom Lane wrote: > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > > I am not seeing the failure here on BSD/OS. I just fixed the > > > libpq-int.h problem. Please update to cvs current and let me know what > > > you see. > > > > FWIW, libpq seems to build fine here (HPUX 10.20) both before and after > > your latest commit. Rod should probably mention what platform he's > > using, and where it defines struct timeval... > > I still have to wait another 30 minutes before I can update to the > latest revision, but here's what's needed: > > > bash-2.05b$ uname -a > FreeBSD jester 4.6-RELEASE FreeBSD 4.6-RELEASE #8: Fri Jul 19 23:45:16 > EDT 2002 root@jester:/usr/obj/usr/src/sys/JESTER i386 > > [ Attachment, skipping... ] -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] cvs-tip broken
On Sat, 2002-08-17 at 22:08, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I am not seeing the failure here on BSD/OS. I just fixed the
> > libpq-int.h problem. Please update to cvs current and let me know what
> > you see.
>
> FWIW, libpq seems to build fine here (HPUX 10.20) both before and after
> your latest commit. Rod should probably mention what platform he's
> using, and where it defines struct timeval...
I still have to wait another 30 minutes before I can update to the
latest revision, but here's what's needed:
bash-2.05b$ uname -a
FreeBSD jester 4.6-RELEASE FreeBSD 4.6-RELEASE #8: Fri Jul 19 23:45:16
EDT 2002 root@jester:/usr/obj/usr/src/sys/JESTER i386
/*
* Copyright (c) 1982, 1986, 1993
* The Regents of the University of California. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
* 3. All advertising materials mentioning features or use of this software
*must display the following acknowledgement:
* This product includes software developed by the University of
* California, Berkeley and its contributors.
* 4. Neither the name of the University nor the names of its contributors
*may be used to endorse or promote products derived from this software
*without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* @(#)time.h 8.5 (Berkeley) 5/4/95
* $FreeBSD: src/sys/sys/time.h,v 1.42 1999/12/29 04:24:48 peter Exp $
*/
#ifndef _SYS_TIME_H_
#define _SYS_TIME_H_
#include
/*
* Structure returned by gettimeofday(2) system call,
* and used in other calls.
*/
struct timeval {
long tv_sec; /* seconds */
long tv_usec; /* and microseconds */
};
#ifndef _TIMESPEC_DECLARED
#define _TIMESPEC_DECLARED
struct timespec {
time_t tv_sec; /* seconds */
long tv_nsec; /* and nanoseconds */
};
#endif
#define TIMEVAL_TO_TIMESPEC(tv, ts) \
do {\
(ts)->tv_sec = (tv)->tv_sec;\
(ts)->tv_nsec = (tv)->tv_usec * 1000; \
} while (0)
#define TIMESPEC_TO_TIMEVAL(tv, ts) \
do {\
(tv)->tv_sec = (ts)->tv_sec;\
(tv)->tv_usec = (ts)->tv_nsec / 1000; \
} while (0)
struct timezone {
int tz_minuteswest; /* minutes west of Greenwich */
int tz_dsttime; /* type of dst correction */
};
#define DST_NONE 0 /* not on dst */
#define DST_USA 1 /* USA style dst */
#define DST_AUST 2 /* Australian style dst */
#define DST_WET 3 /* Western European dst */
#define DST_MET 4 /* Middle European dst */
#define DST_EET 5 /* Eastern European dst */
#define DST_CAN 6 /* Canada */
/*
* Structure used to interface to the machine dependent hardware support
* for timekeeping.
*
* A timecounter is a (hard or soft) binary counter which has two properties:
** it runs at a fixed, known frequency.
** it must not roll over in less than (1 + delta)/HZ seconds. "delta"
* is expected to be less than 20 msec, but no hard data has been
* collected on this. 16 bit at 5 MHz (31 msec) is known to work.
*
* get_timecount() reads the counter.
*
* counter_mask removes unimplemented bits from the count value.
*
* frequency is the counter frequency in hz.
*
* name is a short mnemonic name for this counter.
*
* cost is a measure of how long time it takes to read the counter.
*
* adjustment [PPM << 16] which means that the smallest unit of correction
* you can apply amounts to 481.5 usec/year.
*
* scale_micro [2^32 * usec/tick].
* scale_nano_i [ns/tick].
* scale_nano_f [(ns/2^32)/tick].
*
* offset_count is the contents of the counter which corresponds to the
* rest of the offset_* values.
*
* offset_sec [s].
* offset_micro [usec].
* offset_nano [ns/2^32] is misnamed, the real unit is .23283064365...
* attoseconds (10E-18) and before you ask: yes, they are in fact
*
Re: [HACKERS] Open 7.3 items
Bruce Momjian <[EMAIL PROTECTED]> writes: > OK, here is the patch with the suggested changes. I am sending the > patch to hackers because there has been so much interest in this. One minor gripe: > + /* If user@, it is a global user, remove '@' */ > + if (strchr(port->user, '@') == port->user + strlen(port->user)-1) This code is correct, but it tempts someone to replace the strchr() with a single-character check on the last character of the string. Which would introduce the security hole we discussed before. The code is okay, but *please* improve the comment to point out that you are also excluding the case where there are @'s to the left of the last character. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] compile warnings in CVS
I have applied patches to the regression test to fix this. Thanks. --- Neil Conway wrote: > Neil Conway <[EMAIL PROTECTED]> writes: > > I get the following compiling the current CVS code with gcc 3.1: > > I also get 4 regression test failures, due to Gavin's improvements to > the parser error messages. AFAICT no actual problems, the expected > error message strings just needed to be updated. > > Cheers, > > Neil > > -- > Neil Conway <[EMAIL PROTECTED]> > PGP Key ID: DB3C29FC > > > ---(end of broadcast)--- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to [EMAIL PROTECTED] so that your > message can get through to the mailing list cleanly > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] cvs-tip broken
The code was clearly wrong, mentioning timeval with no time.h nor sys/types.h include. My patches should fix him [good]. :-) Who used to say, "I will fix him good"? I don't remember. --- Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > I am not seeing the failure here on BSD/OS. I just fixed the > > libpq-int.h problem. Please update to cvs current and let me know what > > you see. > > FWIW, libpq seems to build fine here (HPUX 10.20) both before and after > your latest commit. Rod should probably mention what platform he's > using, and where it defines struct timeval... > > regards, tom lane > > ---(end of broadcast)--- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] cvs-tip broken
Bruce Momjian <[EMAIL PROTECTED]> writes: > I am not seeing the failure here on BSD/OS. I just fixed the > libpq-int.h problem. Please update to cvs current and let me know what > you see. FWIW, libpq seems to build fine here (HPUX 10.20) both before and after your latest commit. Rod should probably mention what platform he's using, and where it defines struct timeval... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] cvs-tip broken
I am not seeing the failure here on BSD/OS. I just fixed the libpq-int.h problem. Please update to cvs current and let me know what you see. --- Rod Taylor wrote: > n file included from fe-connect.c:24: > libpq-int.h:337: warning: `struct timeval' declared inside parameter > list > libpq-int.h:337: warning: its scope is only this definition or > declaration, which is probably not what you want. > fe-connect.c: In function `connectDBComplete': > fe-connect.c:1060: storage size of `remains' isn't known > fe-connect.c:1060: storage size of `finish_time' isn't known > fe-connect.c:1060: storage size of `start_time' isn't known > fe-connect.c:1081: warning: suggest parentheses around && within || > fe-connect.c:1086: warning: implicit declaration of function > `gettimeofday' > fe-connect.c:1106: warning: passing arg 4 of `pqWaitTimed' from > incompatible pointer type > fe-connect.c:1114: warning: passing arg 4 of `pqWaitTimed' from > incompatible pointer type > fe-connect.c:1060: warning: unused variable `start_time' > fe-connect.c:1060: warning: unused variable `finish_time' > fe-connect.c:1060: warning: unused variable `remains' > > > > > > ---(end of broadcast)--- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to [EMAIL PROTECTED] so that your > message can get through to the mailing list cleanly > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Remove implicit unique index creation on SERIAL columns?
Joe Conway <[EMAIL PROTECTED]> writes: > I agree 100%. If you want an index, unique constraint, or primary key on > a SERIAL, I think you should explicitly add it. SERIAL should give me a > column that automatically increments -- no more, no less. Hmm, do you also want to eliminate the implicit NOT NULL constraint? I think that efficiency and orthogonality are adequate reasons for dissociating UNIQUE from SERIAL. The efficiency argument is pretty weak in the case of the NOT NULL part, though, so maybe backwards compatibility should win out there. Another line of thought: as near as I can tell, SQL92 allows defaults and CHECK constraints to be associated with domains. Taking the viewpoint that SERIAL is a domain would say that the DEFAULT nextval() is okay, and CHECK NOT NULL is okay, but UNIQUE is not okay to be implied by the domain type. Perhaps the SQL authors knew what they were doing when they made that restriction... (Note that although I just dissuaded Rod from actually turning SERIAL into a domain on compatibility grounds, I don't see any reason why we shouldn't use the spec's rules about domains to reason about how it should work. In a slightly longer timeframe we may decide that we do want to make it a domain.) regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] cvs-tip broken
n file included from fe-connect.c:24: libpq-int.h:337: warning: `struct timeval' declared inside parameter list libpq-int.h:337: warning: its scope is only this definition or declaration, which is probably not what you want. fe-connect.c: In function `connectDBComplete': fe-connect.c:1060: storage size of `remains' isn't known fe-connect.c:1060: storage size of `finish_time' isn't known fe-connect.c:1060: storage size of `start_time' isn't known fe-connect.c:1081: warning: suggest parentheses around && within || fe-connect.c:1086: warning: implicit declaration of function `gettimeofday' fe-connect.c:1106: warning: passing arg 4 of `pqWaitTimed' from incompatible pointer type fe-connect.c:1114: warning: passing arg 4 of `pqWaitTimed' from incompatible pointer type fe-connect.c:1060: warning: unused variable `start_time' fe-connect.c:1060: warning: unused variable `finish_time' fe-connect.c:1060: warning: unused variable `remains' ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] compile warnings in CVS
Yes, very nanny-ish. Not sure how to turn it off. --- Tom Lane wrote: > Neil Conway <[EMAIL PROTECTED]> writes: > > pg_controldata.c: In function `main': > > pg_controldata.c:91: warning: `%c' yields only last 2 digits of year in some >locales > > pg_controldata.c:93: warning: `%c' yields only last 2 digits of year in some >locales > > Yeah. I was willing to ignore that while pg_controldata was in contrib, > but it's much more annoying when it's in the main tree. Anyone know if > gcc has a --not-quite-so-nannyish warnings mode? > > IMHO %c is a perfectly reasonable format choice --- the strftime man > page defines it as > %cLocale's appropriate date and time representation. > While we could go over to some %Y-%M-etc-etc notation, that doesn't > strike me as a step forward. pg_controldata's output should be > conveniently human-readable IMHO, and that means following local > conventions. > > Another alternative is > char *fmt = "%c"; > ... > strftime(..., fmt, ...); > > which I think will probably defeat gcc's check (haven't tried it > though). > > Does anyone want to argue that %c is actually a bad choice? I think > gcc's just being unreasonable here, but maybe I'm missing something > (and no, Y2K arguments won't change my mind). > > regards, tom lane > > ---(end of broadcast)--- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to [EMAIL PROTECTED] so that your > message can get through to the mailing list cleanly > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] compile warnings in CVS
OK, I have fixed the first two with the following patch. The second
pair Tom has commented on.
---
Neil Conway wrote:
> I get the following compiling the current CVS code with gcc 3.1:
>
> ...
> fe-connect.c: In function `connectDBComplete':
> fe-connect.c:1081: warning: suggest parentheses around && within ||
> fe-connect.c:1086: warning: implicit declaration of function `gettimeofday'
> ...
> pg_controldata.c: In function `main':
> pg_controldata.c:91: warning: `%c' yields only last 2 digits of year in some locales
> pg_controldata.c:93: warning: `%c' yields only last 2 digits of year in some locales
>
> Cheers,
>
> Neil
>
> --
> Neil Conway <[EMAIL PROTECTED]>
> PGP Key ID: DB3C29FC
>
>
> ---(end of broadcast)---
> TIP 4: Don't 'kill -9' the postmaster
>
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: src/interfaces/libpq/fe-connect.c
===
RCS file: /cvsroot/pgsql-server/src/interfaces/libpq/fe-connect.c,v
retrieving revision 1.192
diff -c -r1.192 fe-connect.c
*** src/interfaces/libpq/fe-connect.c 17 Aug 2002 12:33:17 - 1.192
--- src/interfaces/libpq/fe-connect.c 18 Aug 2002 00:04:07 -
***
*** 19,24
--- 19,25
#include
#include
#include
+ #include
#include "libpq-fe.h"
#include "libpq-int.h"
***
*** 1078,1095
}
! while (NULL == rp || remains.tv_sec > 0 || remains.tv_sec == 0 &&
remains.tv_usec > 0)
{
/*
* If connecting timeout is set, get current time.
*/
! if ( NULL != rp && -1 == gettimeofday(&start_time, NULL))
{
conn->status = CONNECTION_BAD;
return 0;
}
! /*
* Wait, if necessary. Note that the initial state (just after
* PQconnectStart) is to wait for the socket to select for
* writing.
--- 1079,1096
}
! while (rp == NULL || remains.tv_sec > 0 || (remains.tv_sec == 0 &&
remains.tv_usec > 0))
{
/*
* If connecting timeout is set, get current time.
*/
! if (rp != NULL && gettimeofday(&start_time, NULL) == -1)
{
conn->status = CONNECTION_BAD;
return 0;
}
! /*
* Wait, if necessary. Note that the initial state (just after
* PQconnectStart) is to wait for the socket to select for
* writing.
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Open 7.3 items
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > OK, I think we are doing this backwards. Instead of adding '@' to > > global users, and then removing it in the backend, why don't we have > > local users end with '@', that way, global users continue to connect > > just as they have before, and local users connect with @, so dave@db1 > > connects as 'dave@' and if he has other database access, he can use the > > same 'dave@' name. > > No, *that* would be backwards. In installations that are using this > feature, the vast majority of the users are going to be local ones. > And the global users will be the presumably-more-sophisticated admins. > Putting the onus of the '@' decoration on the local users instead of > the global ones is exactly the wrong way to go. OK, but it looks slightly less ugly. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] CVS Messages
On Fri, Aug 16, 2002 at 05:44:50PM -0400, Rod Taylor wrote: > Is it possible for the cvs emails to include a URL to the appropriate > entries in cvs web? > > The below is current: > > Modified files: > src/backend/utils/adt: ruleutils.c If you're using a Web browser with support for smart bookmarks, nicknames, and javascript: URLs, then you can define a bookmark as something like: javascript:re=/(:.)/;window.location="http://developer.postgresql.org/cvsweb.cgi/pgsql-server/"+"%s".replace(re, "/") and then cut-and-paste the line from the email into your location field using a nickname: pgcvs src/backend/utils/adt: ruleutils.c and have it bring up the cvsweb page. Works with galeon; I guess other recent browsers (Konqueror, Moz, IE?) can do something very similar if not quite identical. Richard ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Remove implicit unique index creation on SERIAL columns?
Rod Taylor wrote: > I'd like to propose dropping the auto-creation of UNIQUE indexes on > serial columns for the following reasons: > > 1. Serials with indexes are quite difficult to handle in pg_dump. It > means that the implicitly created unique index must be destroyed prior > to loading the data, then re-created afterward else risk a performance > hit. > > > 2. SERIAL columns are usually used as the primary key of the table. As > such one must specify PRIMARY KEY at creation time to override the > implicitly created UNIQUE index. > > 3. Consistency with other databases. > > MySQL's AUTO_INCREMENT suggests quite heavily that an index be applied, > but it doesn't appear to do it for you. > > Oracle has SEQUENCES, but it is up to the user to associate them with a > column as per my understanding. At least, thats all I could find. > > SAP -> SERIAL and SERIAL(n). No index is created (creates sequence / > default) FWIW, also MSSQL. I agree 100%. If you want an index, unique constraint, or primary key on a SERIAL, I think you should explicitly add it. SERIAL should give me a column that automatically increments -- no more, no less. Joe ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Remove implicit unique index creation on SERIAL columns?
I'd like to propose dropping the auto-creation of UNIQUE indexes on serial columns for the following reasons: 1. Serials with indexes are quite difficult to handle in pg_dump. It means that the implicitly created unique index must be destroyed prior to loading the data, then re-created afterward else risk a performance hit. 2. SERIAL columns are usually used as the primary key of the table. As such one must specify PRIMARY KEY at creation time to override the implicitly created UNIQUE index. 3. Consistency with other databases. MySQL's AUTO_INCREMENT suggests quite heavily that an index be applied, but it doesn't appear to do it for you. Oracle has SEQUENCES, but it is up to the user to associate them with a column as per my understanding. At least, thats all I could find. SAP -> SERIAL and SERIAL(n). No index is created (creates sequence / default) A nice side effect is that analyze.c will become somewhat cleaner. Any thoughts? Does anyone create serial columns without manually specifying UNIQUE when wanting an index? Examples in our documentation do. See section 5.1.4 in the current docset: http://developer.postgresql.org/docs/postgres/datatype.html Removal of implicit UNIQUE index creation would not affect structure of current or prior db versions -- strictly new tables on 7.3. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] compile warnings in CVS
Neil Conway <[EMAIL PROTECTED]> writes: > pg_controldata.c: In function `main': > pg_controldata.c:91: warning: `%c' yields only last 2 digits of year in some locales > pg_controldata.c:93: warning: `%c' yields only last 2 digits of year in some locales Yeah. I was willing to ignore that while pg_controldata was in contrib, but it's much more annoying when it's in the main tree. Anyone know if gcc has a --not-quite-so-nannyish warnings mode? IMHO %c is a perfectly reasonable format choice --- the strftime man page defines it as %cLocale's appropriate date and time representation. While we could go over to some %Y-%M-etc-etc notation, that doesn't strike me as a step forward. pg_controldata's output should be conveniently human-readable IMHO, and that means following local conventions. Another alternative is char *fmt = "%c"; ... strftime(..., fmt, ...); which I think will probably defeat gcc's check (haven't tried it though). Does anyone want to argue that %c is actually a bad choice? I think gcc's just being unreasonable here, but maybe I'm missing something (and no, Y2K arguments won't change my mind). regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] compile warnings in CVS
Neil Conway <[EMAIL PROTECTED]> writes: > I get the following compiling the current CVS code with gcc 3.1: I also get 4 regression test failures, due to Gavin's improvements to the parser error messages. AFAICT no actual problems, the expected error message strings just needed to be updated. Cheers, Neil -- Neil Conway <[EMAIL PROTECTED]> PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] compile warnings in CVS
I get the following compiling the current CVS code with gcc 3.1: ... fe-connect.c: In function `connectDBComplete': fe-connect.c:1081: warning: suggest parentheses around && within || fe-connect.c:1086: warning: implicit declaration of function `gettimeofday' ... pg_controldata.c: In function `main': pg_controldata.c:91: warning: `%c' yields only last 2 digits of year in some locales pg_controldata.c:93: warning: `%c' yields only last 2 digits of year in some locales Cheers, Neil -- Neil Conway <[EMAIL PROTECTED]> PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: Removing Libraries (Was: Re: [HACKERS] Open 7.3 issues)
On Sat, 17 Aug 2002, Tom Lane wrote: > "Marc G. Fournier" <[EMAIL PROTECTED]> writes: > >> I think the only unknown is whether their CVS's should be moved out of > >> the main tree. > > > Yes, they should be ... > > Certainly. I was a bit worried about losing CVS history, but Marc > indicated he could make the move with history and all, so there's > no downside. Okay, here is what I'd like to suggest ... Bruce, let's start off really simple ... go create a project for libpq++ (I believe someone even volunteered to maintain it?) and let me know once created, and I'll move the CVS directory over for libpq++ and out of the pgsql-server directory ... ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: Removing Libraries (Was: Re: [HACKERS] Open 7.3 issues)
"Marc G. Fournier" <[EMAIL PROTECTED]> writes: >> I think the only unknown is whether their CVS's should be moved out of >> the main tree. > Yes, they should be ... Certainly. I was a bit worried about losing CVS history, but Marc indicated he could make the move with history and all, so there's no downside. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: Removing Libraries (Was: Re: [HACKERS] Open 7.3 issues)
On Sat, 17 Aug 2002, Bruce Momjian wrote: > Marc G. Fournier wrote: > > Chris has made code changes to GBorg to allow for this based on requests > > from Dave Page (ie. PgAdminII) ... so there is no problems with that ... > > > > As for keeping them in our main CVS, the more we put over onto GBorg, the > > more it will get used, test, debugged, pounded and stabilized ... hell, > > maybe some of the 'dead projects' that are on GBorg will come alive again > > also if ppl are going to GBorg and find them, download them and hit the > > authors for fixes :) > > > > But, moving the interfaces over will at least give ppl a reason to go over > > and see what is there ... > > OK, so create gborg projects for all interfaces, and allow them to > release independently. I think we have agreement on that. It can only > be a win. That also gives us a mailing list and bug tracking for each > interface, which is nice. > > I think the only unknown is whether their CVS's should be moved out of > the main tree. Yes, they should be ... maintaining sources in two places would be 'nightmarish' *and* at least GBorg will give a maintainer the ability to add other developers to have CVS access as well, or transferrign maintainership over to someone else ... GBorg is setup so that each project has its own CVSROOT, and its own access controls ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Open 7.3 items
Bruce Momjian <[EMAIL PROTECTED]> writes: > OK, I think we are doing this backwards. Instead of adding '@' to > global users, and then removing it in the backend, why don't we have > local users end with '@', that way, global users continue to connect > just as they have before, and local users connect with @, so dave@db1 > connects as 'dave@' and if he has other database access, he can use the > same 'dave@' name. No, *that* would be backwards. In installations that are using this feature, the vast majority of the users are going to be local ones. And the global users will be the presumably-more-sophisticated admins. Putting the onus of the '@' decoration on the local users instead of the global ones is exactly the wrong way to go. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: Removing Libraries (Was: Re: [HACKERS] Open 7.3 issues)
Marc G. Fournier wrote: > Chris has made code changes to GBorg to allow for this based on requests > from Dave Page (ie. PgAdminII) ... so there is no problems with that ... > > As for keeping them in our main CVS, the more we put over onto GBorg, the > more it will get used, test, debugged, pounded and stabilized ... hell, > maybe some of the 'dead projects' that are on GBorg will come alive again > also if ppl are going to GBorg and find them, download them and hit the > authors for fixes :) > > But, moving the interfaces over will at least give ppl a reason to go over > and see what is there ... OK, so create gborg projects for all interfaces, and allow them to release independently. I think we have agreement on that. It can only be a win. That also gives us a mailing list and bug tracking for each interface, which is nice. I think the only unknown is whether their CVS's should be moved out of the main tree. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: Removing Libraries (Was: Re: [HACKERS] Open 7.3 issues)
On Sat, 17 Aug 2002, Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Now, I know one of Marc's goals is to have libpq as a stand-alone > > tarball, but I thought we decided that this _didn't_ require it to be in > > a separate CVS repository. > > Removing libpq is impossible since psql, pg_dump, etc all depend on it. > > > I don't think we should judge libpqxx differently than the other > > interfaces just because it is new. > > The fact that it is new is a strike against it, and the fact that it is > not integrated is a bigger strike against it. > > I think we should move out libpqxx and libpq++ now, and also perl5 if > we are going to put DBD::Pg on gborg rather than in the main distro. > We want to ensure there is a level playing field for libpqxx and DBD::Pg. > > jdbc and odbc should be moved if and only if their maintainers want it. > > I'm not in a hurry to move the rest; they're small and don't generate > a lot of CVS traffic. Note: I'm happy enough seeing ppl starting to consider moving this stuff over to GBorg, I, by no means, expect everything to go overnight, or even before v7.3 ... As I mentioned in another message, I'm also kinda hoping that if we start to divert traffic to GBorg for stuff like this, then some of the other projects might 'come alive' again as well ... ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Open 7.3 items
OK, I think we are doing this backwards. Instead of adding '@' to global users, and then removing it in the backend, why don't we have local users end with '@', that way, global users continue to connect just as they have before, and local users connect with @, so dave@db1 connects as 'dave@' and if he has other database access, he can use the same 'dave@' name. That removes some of the uglification, I think. --- Tom Lane wrote: > BTW, I just thought of a small improvement to your patch that eliminates > some of the ugliness. Suppose that when we recognize an attempt to > connect as a global user (ie, feature flag is on and last character of > username is '@'), we strip off the '@' before proceeding. Then we would > have: > global users appear in pg_shadow as foo > local users appear in pg_shadow as foo@db > and what this would mean is that you can flip between feature-enabled > and feature-disabled states without breaking your global logins. So you > don't need the extra step of creating a "postgres@" before turning on > the feature. (Which was pretty ugly anyway, since even though postgres@ > could be made a superuser, he wouldn't be the same user as postgres --- > this affects table ownership, for example, and would be a serious issue > if you wanted any non-superuser global users.) > > I suppose some might argue that having to say postgres@ to log in, > when your username is really just postgres as far as you can see in the > database, is a tad confusing. But the whole thing is an acknowledged > wart anyway, and I think getting rid of the two problems mentioned above > is worth it. > > Also, if we do this then it's important to strip a trailing '@' only > if it's the *only* one in the given username. Else a local user > 'foo@db1' could cheat to log into db2 by saying username = 'foo@db1@' > with requested database db2. But I can't see any other security hole. > > regards, tom lane > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: Removing Libraries (Was: Re: [HACKERS] Open 7.3 issues)
On Sat, 17 Aug 2002, Bruce Momjian wrote: > OK, I am ready to do the work, but I would like to get a plan of where > we are going. I see in interfaces: > > cli > ecpg > jdbc > libpgeasy > libpgtcl > libpq > libpq++ > libpqxx > odbc > perl5 > python > > and we have Pg:DBD waiting to be added. > > Now, I know one of Marc's goals is to have libpq as a stand-alone > tarball, but I thought we decided that this _didn't_ require it to be in > a separate CVS repository. Ya, this one I had no problem with ... the only thing with libpq that I do request is that it has its own configure so that it can be completely standalone ... but, IMHO, if someone compiles the server, they are going to need libpq, I just want to make sure taht if they want libpq, they don't need the server ... > If we split these up based on activity, we have, in decreasing activity > order: > > jdbc > odbc > libpq > libpqxx > cli > ecpg > libpq++ > libpgtcl > python > libpgeasy > Pg:DBD > perl5 > > We already have separate web sites for jdbc and odbc, and they are in > our main CVS. > > What goals do we have? Do we create gborg accounts for all/most of > these so releases can be made independently of the main server? Do we > move their CVS out of the main tree too? IMHO, yes ... > Let me add that odbc and jdbc have successfully made releases > independent of our server for over a year now. Correct, so they should be the easiest to move out as well ... > I wonder if the best solution is to create gborg accounts for every > interface and keep them in our main CVS, and do independent releases > from there. Should we point to jdbc/odbc.postgresql.org from gborg? Chris has made code changes to GBorg to allow for this based on requests from Dave Page (ie. PgAdminII) ... so there is no problems with that ... As for keeping them in our main CVS, the more we put over onto GBorg, the more it will get used, test, debugged, pounded and stabilized ... hell, maybe some of the 'dead projects' that are on GBorg will come alive again also if ppl are going to GBorg and find them, download them and hit the authors for fixes :) But, moving the interfaces over will at least give ppl a reason to go over and see what is there ... ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [COMMITTERS] pgsql-server/src backend/tcop/postgres.cbacke
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > OK, with two people now asking to have the patch removed, and with no > > comment from Thomas, I have removed the patch. This removes XLogDir > > environment variable, and -X postmaster/postgres/initdb/pg_ctl flag. > > I thought we intended to keep the -X switch for initdb (only), and have > it make a symlink. The majority of the patch wasn't needed, so rather than muck it up, I just backed it all out. If we want that, and I think we do, someone should implent it as a separate patch that people can review. All the work is going to be done in initdb anyway. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: Removing Libraries (Was: Re: [HACKERS] Open 7.3 issues)
Neil Conway wrote: > "Marc G. Fournier" <[EMAIL PROTECTED]> writes: > > Bruce, can you make a project for Pg::DBD? > > Erm, has anyone contacted the maintainer of DBD::Pg? Given that Bruce > doesn't maintain it and AFAIK Jeffrey Baker (the current maintainer) > and hasn't expressed any dissatisfaction with CPAN, I'm not sure why > you'd like to move the software to GBorg... Uh, I got OK from Edmund. I haven't talked to Jeffrey but I thought someone else had. I thought he had just taken it over and was OK with us handling it. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: Removing Libraries (Was: Re: [HACKERS] Open 7.3 issues)
"Marc G. Fournier" <[EMAIL PROTECTED]> writes: > Bruce, can you make a project for Pg::DBD? Erm, has anyone contacted the maintainer of DBD::Pg? Given that Bruce doesn't maintain it and AFAIK Jeffrey Baker (the current maintainer) and hasn't expressed any dissatisfaction with CPAN, I'm not sure why you'd like to move the software to GBorg... Cheers, Neil -- Neil Conway <[EMAIL PROTECTED]> PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] where to put NO_MKTIME_BEFORE_1970?
Tom Lane writes: > Really what we need is a test on the glibc version, which seems a > bit difficult. Well, it's not that difficult to figure out the version (run /lib/libc.so.6), but I'm afraid the version is not going to tell you anything. For instance, the libc versions that are claimed to have the problem in Red Hat releases don't appear to have that problem here. > In any case we don't currently have a mechanism for reflecting whatever > configure would discover into the resultmap. That would appear to be very tricky. Maybe we need to misappropriate the alternate result file mechanism that was intended for the locale differences. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] more fulltextindex stuff
Christopher Kings-Lynne writes: > I notice that the new default for the contrib Makefiles is to build > libfti.so, etc. instead of the old fti.so. The default is to build nothing ... (?) > Won't this cause dump restore problems for everyone already using the > contrib? No, because what is build is not what is installed. > Anyone mind if I change it to use MODULES instead of MODULE_big for > backwards compatibility? MODULES_big can only build one shared object per directory but it can contain several object files. That is the tradeoff. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [COMMITTERS] pgsql-server/src backend/tcop/postgres.cbacke
Bruce Momjian <[EMAIL PROTECTED]> writes: > OK, with two people now asking to have the patch removed, and with no > comment from Thomas, I have removed the patch. This removes XLogDir > environment variable, and -X postmaster/postgres/initdb/pg_ctl flag. I thought we intended to keep the -X switch for initdb (only), and have it make a symlink. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: Removing Libraries (Was: Re: [HACKERS] Open 7.3 issues)
Bruce Momjian <[EMAIL PROTECTED]> writes: > Now, I know one of Marc's goals is to have libpq as a stand-alone > tarball, but I thought we decided that this _didn't_ require it to be in > a separate CVS repository. Removing libpq is impossible since psql, pg_dump, etc all depend on it. > I don't think we should judge libpqxx differently than the other > interfaces just because it is new. The fact that it is new is a strike against it, and the fact that it is not integrated is a bigger strike against it. I think we should move out libpqxx and libpq++ now, and also perl5 if we are going to put DBD::Pg on gborg rather than in the main distro. We want to ensure there is a level playing field for libpqxx and DBD::Pg. jdbc and odbc should be moved if and only if their maintainers want it. I'm not in a hurry to move the rest; they're small and don't generate a lot of CVS traffic. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [COMMITTERS] pgsql-server/src backend/tcop/postgres.cbacke
OK, with two people now asking to have the patch removed, and with no comment from Thomas, I have removed the patch. This removes XLogDir environment variable, and -X postmaster/postgres/initdb/pg_ctl flag. I have also removed the code that dynamically sized xlogdir. I will post the patch to patches, and keep the patch here in case it is needed later. --- Curt Sampson wrote: > On Fri, 16 Aug 2002, Bruce Momjian wrote: > > > Part of the reason we can't "just continue to use the symlink method" is > > that the PGXLOG environment variable situation is currently in CVS > > beyond initdb and in postmaster, postgres, and pg_ctl, so we do have to > > do something before 7.3 or we will have new environment variable > > handling in all those commands, and I don't think we have agreement on > > that. > > Well, let's take it out, then, and use the symlink instead. It may > be in CVS now, but it's never been in a release, so there should > be no problem with removing it. > > I think we've got some pretty strong opinions here that distributing > configuration information amongst multiple environment variables > is a Bad Idea. > > cjs > -- > Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org > Don't you know, in this new Dark Age, we're all light. --XTC > > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] TODO item: make pg_dump use dependencies to choose dump order
Added: * Use dependency information to dump data in proper order --- Tom Lane wrote: > I can't find any TODO item that mentions fixing pg_dump's deficiencies > concerning choosing an order to dump the database objects in. The > existing method (basically, dump in OID order) tends to fail in > situations where you've used ALTER TABLE, and in any case it breaks down > completely after OID wraparound. > > When using a 7.3 or later database, pg_dump could use the pg_depend > entries to deduce a safe order for dumping objects. This will be a > big rewrite and I don't see it happening for 7.3, but I think it > should be on the TODO list. > > regards, tom lane > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] TODO item: make pg_dump use dependencies to choose dump order
I can't find any TODO item that mentions fixing pg_dump's deficiencies concerning choosing an order to dump the database objects in. The existing method (basically, dump in OID order) tends to fail in situations where you've used ALTER TABLE, and in any case it breaks down completely after OID wraparound. When using a 7.3 or later database, pg_dump could use the pg_depend entries to deduce a safe order for dumping objects. This will be a big rewrite and I don't see it happening for 7.3, but I think it should be on the TODO list. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: Removing Libraries (Was: Re: [HACKERS] Open 7.3 issues)
Marc G. Fournier wrote: > On Thu, 15 Aug 2002, Peter Eisentraut wrote: > > > > integrate or remove new libpqxx > > > integrate or add to gborg Pg:DBD > > > > > > Seems like gborg is the place for these. > > > > I would volunteer to package libpq++ separately. > > Okay, the procedure is simple, but where do we want to put this? Do we > want to move the extracted libraries over to gborg (would be my first > preference), or keep them in the core repository? > > Regardless of which, the extraction is simple ... but if GBorg, if you go > over and make a project and let me know what it is, I can move the library > from our CVS repository straight over there, so that we lose no logs or > anything ... just let me know its created ... > > Bruce, can you make a project for Pg::DBD? OK, I am ready to do the work, but I would like to get a plan of where we are going. I see in interfaces: cli ecpg jdbc libpgeasy libpgtcl libpq libpq++ libpqxx odbc perl5 python and we have Pg:DBD waiting to be added. Now, I know one of Marc's goals is to have libpq as a stand-alone tarball, but I thought we decided that this _didn't_ require it to be in a separate CVS repository. If we split these up based on activity, we have, in decreasing activity order: jdbc odbc libpq libpqxx cli ecpg libpq++ libpgtcl python libpgeasy Pg:DBD perl5 We already have separate web sites for jdbc and odbc, and they are in our main CVS. What goals do we have? Do we create gborg accounts for all/most of these so releases can be made independently of the main server? Do we move their CVS out of the main tree too? I don't think we should judge libpqxx differently than the other interfaces just because it is new. We should find a consistent solution and apply that to all of these interfaces. Let me add that odbc and jdbc have successfully made releases independent of our server for over a year now. I wonder if the best solution is to create gborg accounts for every interface and keep them in our main CVS, and do independent releases from there. Should we point to jdbc/odbc.postgresql.org from gborg? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Better handling of parse errors
Patch applied. Thanks. --- Gavin Sherry wrote: > On Wed, 14 Aug 2002, Tom Lane wrote: > > > Gavin Sherry <[EMAIL PROTECTED]> writes: > > > ... do we want to modify every 7.2 error message? > > > > Nyet ... but I don't think tacking an offset onto the end of > > "parse error at or near foo" messages is likely to cause the > > sort of generalized havoc you suggest ... > > In that case, attached is a patch which locates the beginning of the > offending token more efficiently (per your suggestion of using > scanbuf). The new patch does the same as before: > > template1=# select * frum pg_class; > ERROR: parser: parse error at or near "frum" at character 10 > > It also implement's Tom's suggestion: > > template1=# select * from pg_class where\g > ERROR: parse: parse error at end of input > > Gavin Content-Description: [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
