Re: [HACKERS] [PATCHES] drop if exists remainder
Jim C. Nasby wrote: Important as you are, "one swallow does not make a summer". On the other hand, unless we want the lists filling up with a bunch of +1 posts, it's probably better to assume that unless someone objects a patch would be accepted. What happened was that Tom objected to (or at least queried the need for) the patch on the grounds that it was bloat that nobody had asked for. And when I asked I wasn't exactly deluged with requests to commit, so I concluded that it was not generally wanted. Since then I have had probably 10 requests for it, so I am now going to work to update it and will post a revised patch. cheers andrew ---(end of broadcast)--- TIP 1: 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] [PATCHES] drop if exists remainder
On Thu, Jun 08, 2006 at 12:34:54PM -0400, Andrew Dunstan wrote: > David Fetter wrote: > >On Thu, Jun 08, 2006 at 09:43:19AM -0400, Andrew Dunstan wrote: > > > >>OK there does seem to be some demand for this, so I will rework the > >>patch, and hope to get it done by feature freeze - it has bitrotted > >>with 7 merge conflicts, including the grammar file, so I need to > >>look carefully at that. Pity people didn't speak up when this was > >>first raised. :-) > >> > > > >I did :) > > > > > > > Important as you are, "one swallow does not make a summer". On the other hand, unless we want the lists filling up with a bunch of +1 posts, it's probably better to assume that unless someone objects a patch would be accepted. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] drop if exists remainder
David Fetter wrote: On Thu, Jun 08, 2006 at 09:43:19AM -0400, Andrew Dunstan wrote: OK there does seem to be some demand for this, so I will rework the patch, and hope to get it done by feature freeze - it has bitrotted with 7 merge conflicts, including the grammar file, so I need to look carefully at that. Pity people didn't speak up when this was first raised. :-) I did :) Important as you are, "one swallow does not make a summer". cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] drop if exists remainder
On Thu, Jun 08, 2006 at 09:43:19AM -0400, Andrew Dunstan wrote: > OK there does seem to be some demand for this, so I will rework the > patch, and hope to get it done by feature freeze - it has bitrotted > with 7 merge conflicts, including the grammar file, so I need to > look carefully at that. Pity people didn't speak up when this was > first raised. :-) I did :) Cheers, D -- David Fetter <[EMAIL PROTECTED]> http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! ---(end of broadcast)--- TIP 1: 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] [PATCHES] drop if exists remainder
Josh Berkus wrote: Tom, What's the consensus on this? Nobody else has chimed in, so I'm inclined to do no more on the gounds of insufficient demand. Let's decide before too much bitrot occurs, though. +1 :) +1 We were talking about this on IRC, and I feel that if we're going to do "IF EXISTS" for any objects, we should do it for all objects. Otherwise we risk a considerable amount of user confusion. OK there does seem to be some demand for this, so I will rework the patch, and hope to get it done by feature freeze - it has bitrotted with 7 merge conflicts, including the grammar file, so I need to look carefully at that. Pity people didn't speak up when this was first raised. :-) cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] drop if exists remainder
Tom, > > > What's the consensus on this? Nobody else has chimed in, so I'm > > > inclined to do no more on the gounds of insufficient demand. Let's > > > decide before too much bitrot occurs, though. > > > > +1 :) > > +1 We were talking about this on IRC, and I feel that if we're going to do "IF EXISTS" for any objects, we should do it for all objects. Otherwise we risk a considerable amount of user confusion. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] drop if exists remainder
On Saturday 04 March 2006 22:24, David Fetter wrote:
> On Fri, Mar 03, 2006 at 03:35:24PM -0500, Andrew Dunstan wrote:
> > Bruce Momjian wrote:
> > >Christopher Kings-Lynne wrote:
> >
> > What's the consensus on this? Nobody else has chimed in, so I'm inclined
> > to do no more on the gounds of insufficient demand. Let's decide before
> > too much bitrot occurs, though.
>
> +1 :)
>
+1
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] drop if exists remainder
On Fri, Mar 03, 2006 at 03:35:24PM -0500, Andrew Dunstan wrote: > Bruce Momjian wrote: > > >Christopher Kings-Lynne wrote: > > > > > What's the consensus on this? Nobody else has chimed in, so I'm inclined > to do no more on the gounds of insufficient demand. Let's decide before > too much bitrot occurs, though. +1 :) Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 415 235 3778 Remember to vote! ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] drop if exists remainder
Andrew Dunstan wrote: > >>>Chris KL said it should be done for all on the grounds of consistency. > >>>But I will happily stop right now if that's not the general view - I'm > >>>only doing this to complete something I started. > >>> > >>> > >>Well, my use-case was to be able to wrap "pg_dump -c" output in > >>begin/commit tags and being able to run and re-run such dumps without > >>errors. Basically I don't like 'acceptable errors' when restoring dumps > >>:) They just confuse newer users especially. > >> > >>I also just like consistency :) > >> > >> > > > >Makes sense. > > > > > > > > What's the consensus on this? Nobody else has chimed in, so I'm inclined > to do no more on the gounds of insufficient demand. Let's decide before > too much bitrot occurs, though. I kind of liked it, but I think I was the only one. -- Bruce Momjian http://candle.pha.pa.us SRA OSS, Inc. http://www.sraoss.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] drop if exists remainder
Bruce Momjian wrote: Christopher Kings-Lynne wrote: Here's a first draft patch for DROP ... IF EXISTS for the remaining cases, namely: LANGUAGE, TABLESPACE, TRIGGER OPERATOR CLASS, FUNCTION, AGGREGATE, OPERATOR, CAST and RULE. At what point does this stop being useful and become mere bloat? The only case I can ever recall being actually asked for was the TABLE case ... Chris KL said it should be done for all on the grounds of consistency. But I will happily stop right now if that's not the general view - I'm only doing this to complete something I started. Well, my use-case was to be able to wrap "pg_dump -c" output in begin/commit tags and being able to run and re-run such dumps without errors. Basically I don't like 'acceptable errors' when restoring dumps :) They just confuse newer users especially. I also just like consistency :) Makes sense. What's the consensus on this? Nobody else has chimed in, so I'm inclined to do no more on the gounds of insufficient demand. Let's decide before too much bitrot occurs, though. cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] drop if exists remainder
Christopher Kings-Lynne wrote: > >>> Here's a first draft patch for DROP ... IF EXISTS for the remaining > >>> cases, namely: LANGUAGE, TABLESPACE, TRIGGER OPERATOR CLASS, > >>> FUNCTION, AGGREGATE, OPERATOR, CAST and RULE. > >>> > >> > >> At what point does this stop being useful and become mere bloat? > >> The only case I can ever recall being actually asked for was the > >> TABLE case ... > > > > Chris KL said it should be done for all on the grounds of consistency. > > But I will happily stop right now if that's not the general view - I'm > > only doing this to complete something I started. > > Well, my use-case was to be able to wrap "pg_dump -c" output in > begin/commit tags and being able to run and re-run such dumps without > errors. Basically I don't like 'acceptable errors' when restoring dumps > :) They just confuse newer users especially. > > I also just like consistency :) Makes sense. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] drop if exists remainder
Here's a first draft patch for DROP ... IF EXISTS for the remaining cases, namely: LANGUAGE, TABLESPACE, TRIGGER OPERATOR CLASS, FUNCTION, AGGREGATE, OPERATOR, CAST and RULE. At what point does this stop being useful and become mere bloat? The only case I can ever recall being actually asked for was the TABLE case ... Chris KL said it should be done for all on the grounds of consistency. But I will happily stop right now if that's not the general view - I'm only doing this to complete something I started. Well, my use-case was to be able to wrap "pg_dump -c" output in begin/commit tags and being able to run and re-run such dumps without errors. Basically I don't like 'acceptable errors' when restoring dumps :) They just confuse newer users especially. I also just like consistency :) Chris ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] drop if exists remainder
Bruce Momjian wrote:
However, I see CREATE ROLE doesn't have REPLACE functionality, so what
is the logic of when we need IF EXISTS and when we don't? Perhaps they
all should have it, and the REPLACE is just for objects you want to
replace but keep existing linkage in place.
That was my understanding. I think these are orthogonal issues.
Another issue was MySQL compatibility. AFAIK we achieved that when we
did database, following
{ table view index sequence schema type domain conversion}, which pretty
much all had to be done together, as they share the same statement node
type.
cheers
andrew
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] drop if exists remainder
Andrew Dunstan wrote: > > > Tom Lane wrote: > > >Andrew Dunstan <[EMAIL PROTECTED]> writes: > > > > > >>Here's a first draft patch for DROP ... IF EXISTS for the remaining > >>cases, namely: LANGUAGE, TABLESPACE, TRIGGER OPERATOR CLASS, FUNCTION, > >>AGGREGATE, OPERATOR, CAST and RULE. > >> > >> > > > >At what point does this stop being useful and become mere bloat? > >The only case I can ever recall being actually asked for was the > >TABLE case ... > > > > > > > > > > Chris KL said it should be done for all on the grounds of consistency. > But I will happily stop right now if that's not the general view - I'm > only doing this to complete something I started. I am thinking we should have IF EXISTS support for every object that has CREATE OR REPLACE functionality, plus objects that have storage like table and perhaps index. However, I see CREATE ROLE doesn't have REPLACE functionality, so what is the logic of when we need IF EXISTS and when we don't? Perhaps they all should have it, and the REPLACE is just for objects you want to replace but keep existing linkage in place. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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: Don't 'kill -9' the postmaster
Re: [PATCHES] drop if exists remainder
Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: Here's a first draft patch for DROP ... IF EXISTS for the remaining cases, namely: LANGUAGE, TABLESPACE, TRIGGER OPERATOR CLASS, FUNCTION, AGGREGATE, OPERATOR, CAST and RULE. At what point does this stop being useful and become mere bloat? The only case I can ever recall being actually asked for was the TABLE case ... Chris KL said it should be done for all on the grounds of consistency. But I will happily stop right now if that's not the general view - I'm only doing this to complete something I started. cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] drop if exists remainder
Andrew Dunstan <[EMAIL PROTECTED]> writes: > Here's a first draft patch for DROP ... IF EXISTS for the remaining > cases, namely: LANGUAGE, TABLESPACE, TRIGGER OPERATOR CLASS, FUNCTION, > AGGREGATE, OPERATOR, CAST and RULE. At what point does this stop being useful and become mere bloat? The only case I can ever recall being actually asked for was the TABLE case ... regards, tom lane ---(end of broadcast)--- TIP 1: 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
[PATCHES] drop if exists remainder
Here's a first draft patch for DROP ... IF EXISTS for the remaining
cases, namely: LANGUAGE, TABLESPACE, TRIGGER OPERATOR CLASS, FUNCTION,
AGGREGATE, OPERATOR, CAST and RULE.
comments welcome - working on tests/docs now.
cheers
andrew
Index: src/backend/commands/aggregatecmds.c
===
RCS file: /cvsroot/pgsql/src/backend/commands/aggregatecmds.c,v
retrieving revision 1.31
diff -c -r1.31 aggregatecmds.c
*** src/backend/commands/aggregatecmds.c 22 Nov 2005 18:17:08 - 1.31
--- src/backend/commands/aggregatecmds.c 5 Feb 2006 14:29:51 -
***
*** 180,186
else
basetypeID = ANYOID;
! procOid = find_aggregate_func(aggName, basetypeID, false);
/*
* Find the function tuple, do permissions and validity checks
--- 180,196
else
basetypeID = ANYOID;
! procOid = find_aggregate_func(aggName, basetypeID, stmt->missing_ok);
!
! if (stmt->missing_ok &&!OidIsValid(procOid) )
! {
! ereport(NOTICE,
! (errmsg("aggregate %s(%s) does not exist ... skipping",
! NameListToString(aggName),
! (aggType ? format_type_be(basetypeID): "*" ;
!
! return;
! }
/*
* Find the function tuple, do permissions and validity checks
Index: src/backend/commands/functioncmds.c
===
RCS file: /cvsroot/pgsql/src/backend/commands/functioncmds.c,v
retrieving revision 1.70
diff -c -r1.70 functioncmds.c
*** src/backend/commands/functioncmds.c 21 Nov 2005 12:49:31 - 1.70
--- src/backend/commands/functioncmds.c 5 Feb 2006 14:29:51 -
***
*** 687,693
/*
* Find the function, do permissions and validity checks
*/
! funcOid = LookupFuncNameTypeNames(functionName, argTypes, false);
tup = SearchSysCache(PROCOID,
ObjectIdGetDatum(funcOid),
--- 687,703
/*
* Find the function, do permissions and validity checks
*/
! funcOid = LookupFuncNameTypeNames(functionName, argTypes,
! stmt->missing_ok);
!
! if (stmt->missing_ok &&!OidIsValid(funcOid))
! {
! ereport(NOTICE,
! (errmsg("function %s(%s) does not exist ... skipping",
! NameListToString(functionName),
! NameListToString(argTypes;
! return;
! }
tup = SearchSysCache(PROCOID,
ObjectIdGetDatum(funcOid),
***
*** 1402,1411
sourcetypeid = LookupTypeName(stmt->sourcetype);
if (!OidIsValid(sourcetypeid))
! ereport(ERROR,
! (errcode(ERRCODE_UNDEFINED_OBJECT),
! errmsg("source data type %s does not exist",
! TypeNameToString(stmt->sourcetype;
targettypeid = LookupTypeName(stmt->targettype);
if (!OidIsValid(targettypeid))
--- 1412,1429
sourcetypeid = LookupTypeName(stmt->sourcetype);
if (!OidIsValid(sourcetypeid))
! {
! if ( ! stmt->missing_ok )
! ereport(ERROR,
! (errcode(ERRCODE_UNDEFINED_OBJECT),
! errmsg("source data type %s does not exist",
! TypeNameToString(stmt->sourcetype;
! else
! ereport(NOTICE,
! (errmsg("source data type %s does not exist ... skipping",
! TypeNameToString(stmt->sourcetype;
! return;
! }
targettypeid = LookupTypeName(stmt->targettype);
if (!OidIsValid(targettypeid))
Index: src/backend/commands/opclasscmds.c
===
RCS file: /cvsroot/pgsql/src/backend/commands/opclasscmds.c,v
retrieving revision 1.41
diff -c -r1.41 opclasscmds.c
*** src/backend/commands/opclasscmds.c 13 Jan 2006 18:10:25 - 1.41
--- src/backend/commands/opclasscmds.c 5 Feb 2006 14:29:52 -
***
*** 703,724
{
/* Unqualified opclass name, so search the search path */
opcID = OpclassnameGetOpcid(amID, opcname);
if (!OidIsValid(opcID))
! ereport(ERROR,
! (errcode(ERRCODE_UNDEFINED_OBJECT),
! errmsg("operator class \"%s\" does not exist for access method \"%s\"",
! opcname, stmt->amname)));
tuple = SearchSysCache(CLAOID,
ObjectIdGetDatum(opcID),
0, 0, 0);
}
if (!HeapTupleIsValid(tuple))
! ereport(ERROR,
! (errcode(ERRCODE_UNDEFINED_OBJECT),
! errmsg("operator class \"%s\" does not exist for access method \"%s\"",
! NameListToString(stmt->opclassname), stmt->amname)));
opcID = HeapTupleGetOid(tuple);
/* Permission check: must own opclass or its namespace */
--- 703,743
{
/* Unqualified opclass name, so search the search path */
opcID = OpclassnameGetOpcid(amID, opcname);
+
if (!OidIsValid(opcID))
! {
! if (! stmt -> missing_ok )
! ereport(ERROR,
! (errcode(ERRCODE_UNDEFINED_OBJECT),
! errmsg("operator class \"%s\" does not exist for access method \"%s\"",
! opcname, stmt->amname)));
! else
! ereport(NOTICE,
! (errmsg("operator class \"%s\" does not exist for access method \"%s\"",
! opcname, stmt->amname)));
!
!
