Re: [PATCHES] add additional options to CREATE TABLE ... AS

2006-02-15 Thread Simon Riggs
On Tue, 2006-02-14 at 15:38 -0500, Tom Lane wrote: > Neil Conway <[EMAIL PROTECTED]> writes: > > The implementation is pretty ugly -- it clutters ExecuteStmt and Query > > with fields that really do not belong there. Per previous discussion, I > > think it would be better to refactor the CREATE TAB

[PATCHES] BUG #2246: Only call pg_fe_getauthname if none given

2006-02-15 Thread Stephen Frost
* Tom Lane ([EMAIL PROTECTED]) wrote: > Right offhand I like the idea of pushing it into connectOptions2 --- can > you experiment with that? Seems like there is no reason to call > Kerberos if the user supplies the name to connect as. Patch attached. After looking through the code around this I

Re: [PATCHES] BUG #2246: Only call pg_fe_getauthname if none given

2006-02-15 Thread Tom Lane
Stephen Frost <[EMAIL PROTECTED]> writes: > * Tom Lane ([EMAIL PROTECTED]) wrote: >> Right offhand I like the idea of pushing it into connectOptions2 --- can >> you experiment with that? Seems like there is no reason to call >> Kerberos if the user supplies the name to connect as. > Patch attache

Re: [PATCHES] BUG #2246: Only call pg_fe_getauthname if none given

2006-02-15 Thread Stephen Frost
* Tom Lane ([EMAIL PROTECTED]) wrote: > This is probably not a good idea --- changing the API behavior in > pursuit of saving a few cycles is just going to get people mad at us. Fair enough. > I think we'd have to refactor the code so that PQsetdbLogin gets a > PQconninfoOption array, overrides v

Re: [PATCHES] BUG #2246: Only call pg_fe_getauthname if none given

2006-02-15 Thread Tom Lane
Stephen Frost <[EMAIL PROTECTED]> writes: > Perhaps I'm missing something obvious (and if so, I'm sorry) but > couldn't we just build up the character array in PQsetdbLogin to be > passed in to connectOptions1? That's a possibility too, though by the time you've finished building that string (with

Re: [PATCHES] patch fixing the old RETURN NEXT bug

2006-02-15 Thread Sergey E. Koposov
On Sun, 12 Feb 2006, Tom Lane wrote: > "Sergey E. Koposov" <[EMAIL PROTECTED]> writes: > > The problem with that is in fact in pl_exec.c in function > > compatible_tupdesc(), which do not check for the deleted attributes. > > Is that really the only problem? Tom, Are there any problems with tha

Re: [PATCHES] patch fixing the old RETURN NEXT bug

2006-02-15 Thread Tom Lane
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes: > Are there any problems with that patch to not be applied ? Hasn't been reviewed yet ... see nearby discussions about shortage of patch reviewers ... > (Sorry if I'm hurrying) At the moment it's not unusual for nontrivial patches to sit around fo

[PATCHES] constant too large in port/gettimeofday

2006-02-15 Thread Kris Jurka
This patch fixes this warning. gettimeofday.c:35: warning: integer constant is too large for "long" type Kris Jurka Index: src/port/gettimeofday.c === RCS file: /projects/cvsroot/pgsql/src/port/gettimeofday.c,v retrieving revisi

Re: [PATCHES] [HACKERS] Patch Submission Guidelines

2006-02-15 Thread Robert Treat
On Tuesday 14 February 2006 20:42, Robert Treat wrote: > On Tuesday 14 February 2006 16:00, Martijn van Oosterhout wrote: > > > I would like to suggest that we increase substantially the FAQ entries > > > relating to patch submission. By we, I actually mean please could the > > > committers sit dow

Re: [PATCHES] [HACKERS] Patch Submission Guidelines

2006-02-15 Thread Tom Lane
Robert Treat <[EMAIL PROTECTED]> writes: > As stated, the following patch adds a list of patch submission guidelines > based on Simon Riggs suggestions to the developers FAQ. A couple minor comments ... > ! Ensure that your patch is generated against the most recent > version > !