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

Re: pgsql: Unify some tar functionality across different parts

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgresql(dot)org, Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-committers <pgsql-committers(at)postgresql(dot)org>
Subject: Re: pgsql: Unify some tar functionality across different parts
Date: 2013-01-02 16:36:01
Message-ID: 20283.1357144561@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> On Wed, Jan 2, 2013 at 4:14 AM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>>> This seems to have broken plperl builds on Windows.

> I'm not really sure what the best thing is to do here. We can either
> use the fact that we know that uid_t and gid_t are "int" on all our
> platforms, more or less, and change the tar api to use uid_t. Or put
> the tar functions in their own header and make sure we don't include
> that one anywhere that we include the perl headers.

Why are these very tar-specific functions being declared in such a
globally visible spot as port.h?  That seems like a bad idea on its
face.  IMO stuff in port.h ought to be about as globally applicable
as, say, malloc().

If there's actually a reason for that sort of namespace abuse, then
change their parameters to int --- IIRC, the tar format can't support
UIDs wider than 32 bits anyway.

			regards, tom lane


In response to

Responses

pgsql-hackers by date

Next:From: Boszormenyi ZoltanDate: 2013-01-02 16:36:23
Subject: Re: allowing multiple PQclear() calls
Previous:From: Kohei KaiGaiDate: 2013-01-02 16:35:13
Subject: Re: Review of Row Level Security

pgsql-committers by date

Next:From: Magnus HaganderDate: 2013-01-02 16:39:04
Subject: Re: [COMMITTERS] pgsql: Unify some tar functionality across different parts
Previous:From: Alvaro HerreraDate: 2013-01-02 15:32:31
Subject: pgsql: Fix background workers for EXEC_BACKEND

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