Re: Moved simple_prompt()/sprompt.c

I have moved simple_prompt()/sprompt.c into /port. It was used by psql,
pg_dump, and scripts, and had already gotten out of sync with a recent
Win32 password patch.

If a file is needed by three non-backend directories, /port seems to be
the proper place for it.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Bruce Momjian writes:

> If a file is needed by three non-backend directories, /port seems to be
> the proper place for it.

src/port is intended for replacement implementations of standard library
functions. If we make it an "everything that is used in more than one
place" directory, we should be very clear about that strategy. Else,
src/utils might be a better place.

--
Peter Eisentraut peter_e(at)gmx(dot)net

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Bruce Momjian writes:
>> If a file is needed by three non-backend directories, /port seems to be
>> the proper place for it.

> src/port is intended for replacement implementations of standard library
> functions.

I concur, src/port is *not* the right place. src/port is for stuff that
is platform-dependent.

regards, tom lane

Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > Bruce Momjian writes:
> >> If a file is needed by three non-backend directories, /port seems to be
> >> the proper place for it.
>
> > src/port is intended for replacement implementations of standard library
> > functions.
>
> I concur, src/port is *not* the right place. src/port is for stuff that
> is platform-dependent.

Yes, thread.c, path.c, and sprompt.c should be in utils, but how do I do
that? Utils seems to be a place things are pulled from, rather than a
library that goes with every link.

Is it worth creating another library that acts just like /port but is
called utils, or should we just rename the directory to portutils?

I am looking to move fmtId() over to port too so psql can use it. It is
already used by pg_dump, and /scripts.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Yes, thread.c, path.c, and sprompt.c should be in utils, but how do I do
> that? Utils seems to be a place things are pulled from, rather than a
> library that goes with every link.

> Is it worth creating another library that acts just like /port but is
> called utils, or should we just rename the directory to portutils?

path.c is arguably okay material for /port, since it is dealing with
platform-to-platform variations.

sprompt.c is only going to be used by stuff under src/bin. I wonder if
we should create a src/bin/utils directory.

Not sure about thread.c --- perhaps we could just dump it into libpq.
(libpq requires it anyway, no? So why not export it from there and let
the apps atop libpq use the same instance.)

> I am looking to move fmtId() over to port too so psql can use it. It is
> already used by pg_dump, and /scripts.

That's definitely not port/ material. A src/bin/utils/ directory would
make sense for it though.

regards, tom lane

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Yes, thread.c, path.c, and sprompt.c should be in utils, but how do I do
> > that? Utils seems to be a place things are pulled from, rather than a
> > library that goes with every link.
>
> > Is it worth creating another library that acts just like /port but is
> > called utils, or should we just rename the directory to portutils?
>
> path.c is arguably okay material for /port, since it is dealing with
> platform-to-platform variations.
>
> sprompt.c is only going to be used by stuff under src/bin. I wonder if
> we should create a src/bin/utils directory.

I found it used by two contrib modules. I just removed the old
duplicate code because they are already linking with pgport. For this
reason, src/bin/utils is looking worse, so perhaps we should be looking
at /utils and creating a libpgutils library like pgport for 7.5.

> Not sure about thread.c --- perhaps we could just dump it into libpq.
> (libpq requires it anyway, no? So why not export it from there and let
> the apps atop libpq use the same instance.)

Yes, libpq would probably be best until we find someone else who needs
it.

> > I am looking to move fmtId() over to port too so psql can use it. It is
> > already used by pg_dump, and /scripts.
>
> That's definitely not port/ material. A src/bin/utils/ directory would
> make sense for it though.

I am thinking of just leaving fmtId() in /pg_dump and symlinking from
there as /scripts does. It is pretty specific. fmtId() actually links
in /src/backend/parser/keywords.o, so it is a really wild function. If
we put fmtId() in a library, we would need to put keywords.o in there
too, and that is just too weird, and a dependency mess.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073