Re: [PATCHES] polymorphic arguments and return type for PL/pgSQL

[Tom Lane]

Joe Conway [EMAIL PROTECTED] writes:
 With the current linked list, the function is effectively leaked to the 
 end of the session anyway, so I don't think this is any worse. Thoughts?

Don't worry about it now.  If a plpgsql function cache entry is
discarded, we leak far more than just the function struct :-( ... and
most of it has been malloc'd, not palloc'd, so it's very hard to get
back.

Someday plpgsql should be rewritten so that it never malloc's anything,
and all its parse data structures are palloc'd into a memory context
associated with the current function cache entry.  Then it would be
practical to recover the memory associated with an obsoleted cache
entry.  But we've lived without this so far, so I guess it's not causing
many people problems.

regards, tom lane

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [PATCHES] Postgresql.conf, initdb patch

[Peter Eisentraut]

Josh Berkus writes:

 initdb.patch, written by Shridhar, patches initdb so that the LC_*
 localization variables are inserted into postgresql.conf at the point
 commented #LC VARS GO HERE!

It's pretty pointless to use

cat $file | sed 's/.../'

because sed can open files perfectly well:

sed 's/.../' $file

You should clean up the temp files in exit_nicely(), because if someone or
something aborts initdb in the middle, then the trap will at least have a
better chance to remove the files.

Actually, I doubt that it's safe and/or polite to write temporary files in
the current directory.  If you want to see a better way to handle
temporary files in shell scripts, look in configure near occurences of
'mktemp'.

 As I'm not great a patch-making, I've also attached the completed
 postgresql.conf.sample for reference.

Use diff -c instead of plain diff and put the old file first and the new
file second.

-- 
Peter Eisentraut   [EMAIL PROTECTED]


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [PATCHES] Patch for listing runtime option details through server

[Peter Eisentraut]

Aizaz Ahmed writes:

 The attached patch adds the --long-help option to the server executable.

Conceptual comments:

If the option is named --long-help, I'd expect a longer version of
--help, which this is not.  The name should probably involve help
and config to make it clearer what you get.  (Personally, I think
help should go before the qualifying word, but there may be other
opinions.)

Do we really want to encode the notion of option categories into the
source code?  This looks like a pretty large burden to me.  Organizing
the documentation or the sample files in user-friendly ways is one
thing, but if I need to organize the code and new options along those
lines, I'm not sure.

If, on the other hand, we like the code to know about categories,
should this code be capable of generating the sample file
automatically?

I don't think we need two different machine formats -m and -M.  The
machine isn't going to need the column headers anyway.

The help message should be printed by --help, not -h.  In fact, I
don't think there should be a separate subhelp message.  Users know
about --help, and that should give them all information about all
invocation modes right there.

Code comments:

To mark up string literals, where you use translatable(), there is
already a standard function gettext_noop() available.

When inserting lines into an existing help message, please observe the
style conventions (capitalization, punctuation, etc.) of the
surrounding lines.

There is already a file guc.c, why should there be a file pg_guc.c
now?  That doesn't make sense; the names should be differentiated
better.

Why have various things been moved from guc.h to guc_vars.h, which
seems to just split things up uselessly?

Why are there long explanations in some cases only?  Do you plan to
add others later?  I also think the messages should be made more
consistent in various ways, but that can be done later.

Should options not for general use (e.g., session_auth_is_superuser)
be hidden from this tool?  Are they?  What other provisions of this
kind does this tool make?

The GucContext_names are not translatable.  They aren't English words
either.

-- 
Peter Eisentraut   [EMAIL PROTECTED]


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster