Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Moving tablespaces

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-documentation <pgsql-docs(at)postgresql(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] Moving tablespaces
Date: 2011-12-06 15:13:46
Message-ID: CABUevEy9MurQp23B0Z7r3jqDoW4N4BHPwnTgiNqNFY3jAJbFEg@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-docspgsql-hackers
On Tue, Dec 6, 2011 at 16:12, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> AFAICT, it should be as simple as the attached.
>
> Oh, one other thought is that the function body has to be
> conditionalized on HAVE_READLINK (the fact that you forgot that
> somewhere else isn't an excuse for not doing it here).  IIRC,
> only the two built-in tablespaces can exist when not HAVE_READLINK,
> so it seems sufficient to handle those cases and then PG_RETURN_NULL
> (or maybe throw error) when not HAVE_READLINK.

Hmm. good point.

Throwing an error seems a lot more safe in this case than just
returning NULL. Since it's a situtation that really shouldn't happen.
Maybe an assert, but I think a regular ereport(ERROR) would be the
best.


-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

In response to

Responses

pgsql-docs by date

Next:From: Tom LaneDate: 2011-12-06 15:17:13
Subject: Re: [HACKERS] Moving tablespaces
Previous:From: Tom LaneDate: 2011-12-06 15:12:32
Subject: Re: [HACKERS] Moving tablespaces

pgsql-hackers by date

Next:From: Tom LaneDate: 2011-12-06 15:17:13
Subject: Re: [HACKERS] Moving tablespaces
Previous:From: Tom LaneDate: 2011-12-06 15:12:32
Subject: Re: [HACKERS] Moving tablespaces

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group