Re: [HACKERS] command.c breakup

2002-04-14 Thread John Gray
On Sun, 2002-04-14 at 21:58, Rod Taylor wrote: > Sounds fair. I'd have brought it up earlier but was away last week. > > The changes I made are very straight forward and easy enough to redo. I've sent the patch to the -patches list -Please let me know if there are any queries -I will be able to

Re: [HACKERS] command.c breakup

2002-04-14 Thread Rod Taylor
e" <[EMAIL PROTECTED]>; "Hackers" <[EMAIL PROTECTED]> Sent: Sunday, April 14, 2002 4:43 PM Subject: Re: [HACKERS] command.c breakup > On Sun, 2002-04-14 at 21:30, Rod Taylor wrote: > > I'm not exactly sure what you're touching, but could it wait for t

Re: [HACKERS] command.c breakup

2002-04-14 Thread John Gray
On Sun, 2002-04-14 at 21:30, Rod Taylor wrote: > I'm not exactly sure what you're touching, but could it wait for the > below pg_depend patch to be either accepted or rejected? It lightly > fiddles with a number of files in the command and catalog directories. > > http://archives.postgresql.org/

Re: [HACKERS] command.c breakup

2002-04-14 Thread Rod Taylor
I'm not exactly sure what you're touching, but could it wait for the below pg_depend patch to be either accepted or rejected? It lightly fiddles with a number of files in the command and catalog directories. http://archives.postgresql.org/pgsql-patches/2002-04/msg00050.php > > That shouldn't b

Re: [HACKERS] command.c breakup

2002-04-12 Thread John Gray
On Fri, 2002-04-12 at 03:33, Christopher Kings-Lynne wrote: > > Fine. I'll work on that basis. I'll prepare a full-blown patch which can > > be applied Monday -unless anyone else is sitting on uncommitted changes > > to the directory that they want me to wait for? > > Nothing important. Shall I

Re: [HACKERS] command.c breakup

2002-04-11 Thread Christopher Kings-Lynne
> Fine. I'll work on that basis. I'll prepare a full-blown patch which can > be applied Monday -unless anyone else is sitting on uncommitted changes > to the directory that they want me to wait for? Nothing important. Shall I suggest that you do the rearrangement first, and then once everything'

Re: [HACKERS] command.c breakup

2002-04-11 Thread John Gray
On Thu, 2002-04-11 at 15:33, Tom Lane wrote: > > > That shouldn't be too much of a problem in the next couple of weeks - if > > we can decide on a specific day I'll book it into my diary (Any day but > > Wednesday next week would be fine for me). > > I will try to have no uncommitted changes over

Re: [HACKERS] command.c breakup

2002-04-11 Thread Tom Lane
John Gray <[EMAIL PROTECTED]> writes: > I have compiled a new version against current CVS, now also including > references to dependencies (See below). I accept that we'll need to work > round the schema project -in the week since the last message I notice > that namespace support has arrived for

Re: [HACKERS] command.c breakup

2002-04-11 Thread John Gray
On Wed, 2002-04-03 at 16:52, Tom Lane wrote: > John Gray <[EMAIL PROTECTED]> writes: > > Here's my current working draft (doesn't include material from the > > last couple of weeks): > > Please note that there's been pretty substantial revisions in command.c > and creatinh.c over the past couple

Re: [HACKERS] command.c breakup

2002-04-03 Thread Tom Lane
John Gray <[EMAIL PROTECTED]> writes: > Here's my current working draft (doesn't include material from the > last couple of weeks): Please note that there's been pretty substantial revisions in command.c and creatinh.c over the past couple of weeks for schema support. While I think that those tw

Re: [HACKERS] command.c breakup

2002-04-03 Thread John Gray
On Wed, 2002-04-03 at 09:39, Christopher Kings-Lynne wrote: > Hi All, > > With regards to the proposed command.c refactoring... > ..about which I should apologise as I stuck my head above the parapet and then sat on my ideas (mixing metaphors a bit). > I've done it by removing command.c and rep

[HACKERS] command.c breakup

2002-04-03 Thread Christopher Kings-Lynne
Hi All, With regards to the proposed command.c refactoring... I've done it by removing command.c and replacing it with portal.c alter.c lock.c namespace.c Is that a good idea? Will it break too many outstanding patches? Basically the portal fetch/destroy commands go in portal.c, all the Alte