Re: Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist
| От | Alvaro Herrera |
|---|---|
| Тема | Re: Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist |
| Дата | |
| Msg-id | 20131202193718.GC5731@eldon.alvh.no-ip.org обсуждение исходный текст |
| Ответ на | Re: Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist (Dean Rasheed <dean.a.rasheed@gmail.com>) |
| Ответы |
Re: Re: [BUGS] BUG #7873: pg_restore --clean tries to drop
tables that don't exist
|
| Список | pgsql-hackers |
Dean Rasheed escribió:
> +/*
> + * If a schema was explicitly specified, test if it exists. If it does not,
> + * report the schema as missing rather than the child object.
> + */
> +static bool
> +schema_does_not_exist_skipping(List *objname,
> + const char **msg,
> + char **name)
> +{
> + RangeVar *rel;
> +
> + rel = makeRangeVarFromNameList(objname);
> +
> + if (rel->schemaname != NULL &&
> + !OidIsValid(LookupNamespaceNoError(rel->schemaname)))
> + {
> + *msg = gettext_noop("schema \"%s\" does not exist, skipping");
> + *name = rel->schemaname;
> +
> + return true;
> + }
> +
> + return false;
> +}
In success cases, are we leaking a lot of memory? In the error case I
guess it doesn't matter that the RangeVar is getting leaked (we're
aborting anyway), but if we're called and everything turns out to work,
are things cleaned up timely?
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: