Re: Patch to change psql default banner v6
От | Andrew Dunstan |
---|---|
Тема | Re: Patch to change psql default banner v6 |
Дата | |
Msg-id | 482CDD18.6070801@dunslane.net обсуждение исходный текст |
Ответ на | Re: Patch to change psql default banner v6 (David Fetter <david@fetter.org>) |
Ответы |
Re: Patch to change psql default banner v6
|
Список | pgsql-patches |
David Fetter wrote: > On Thu, May 15, 2008 at 06:55:31PM -0400, Andrew Dunstan wrote: > >> David Fetter wrote: >> >>> I hate to bike-shed this even further, but I'd like to make those >>> "incompatibility" messages just go away by making 8.4's psql (and >>> all those going forward) support every living version of Postgres >>> at the time of their release, so 8.4's psql would be able to talk >>> seamlessly to Postgres 7.4 :) >>> >> I think you must have been out in the sun too long. >> > > One thing I really treasure about working on the Postgres project is > frank feedback. :) > I know you know me well enough to realise there was an implied smiley ;-) > >> Just look at the pg_dump code if you want something of an idea of >> what this would involve. >> > > Given that each previous version tied backslash commands to some > particular chunk of SQL, what would be the problem with either > immediately or lazily setting those to the chunks of SQL already > present in previous versions? > > > First, this is not a cost free exercise - it increases code complexity enormously. Second, it's not nearly as easy as that: . new commands have been added . postgres features have been added . catalogs have changed Among other things, help and indeed the available command set would have to become server version sensitive. And you would greatly increase the bar for anyone wanting to add a new command - now they (or someone) would have to work out how the command would or might work n versions back, not just with the current dev version. Doing it lazily isn't acceptable - if we promise \command compatibility with previous server versions then we need to deliver it to the maximum extent possible, and if we don't promise it there's no point in doing this. And, as Tom says, it has nothing really to do with this patch. cheers andrew
В списке pgsql-patches по дате отправления: