Re: splitting *_desc routines

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: splitting *_desc routines
Date: 2012-08-29 20:06:16
Message-ID: 1446.1346270776@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> I looked at Andres' patch and the general idea is rather horrible: it
> links all backend files into the output executable. This is so that the
> *_desc functions can be used from their respective object files, which
> obviously have a lot of requirements for backend infrastructure.

Check.

> So it is my intention to split out the desc() functions out of their
> current files, into their own file, allowing xlogdump to link against
> that and not be forced to link the rest of the backend.

Meh. Can we compromise on one file per xlog rmgr? I don't much care
for the "one big file" idea.

> To solve the stringinfo problem, we would provide a separate
> implementation of it, one that doesn't depend on palloc and elog.

Shim on top of PQExpBuffer seems like the way to go.

An alternative thing that might be worth considering before you go all
in on this is whether the xlogdump functionality shouldn't just be part
of the regular server executable, ie you'd call it with

postgres --xlogdump <arguments>

and the only extra code needed is two lines for another redirect in
main.c. We've already done that for things like --describe-config.
This'd likely be a lot less work than getting the _desc routines to
be operable standalone ...

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2012-08-29 21:05:37 Re: FATAL: bogus data in lock file "postmaster.pid": ""
Previous Message Tom Lane 2012-08-29 19:54:52 Re: MySQL search query is not executing in Postgres DB