Baby girl on Jun 27.
Vadim
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I'm not familiar with the kinds of statistics that are supposed to be
> gathered here, but I suppose their usefulness would be greatly increased
> if they were gathered across all data/actions, not only the ones that the
> users turned them on for. S
Alex Pilosov <[EMAIL PROTECTED]> writes:
> Well, I'm on my way to implement what was discussed on list before.
> I am doing it the way Karel and Jan suggested: creating a
> pg_class/pg_attribute tuple[s] for a function that returns a setof.
What? You shouldn't need pg_class entries for function
Hi:
On 29 Jun 2001, Manuel Sugawara wrote:
> Thomas Lockhart <[EMAIL PROTECTED]> writes:
>
> > > So, I wrote a small perl script which outputs XML for Dia to import.
> > > Works pretty good.
> >
> > Thanks for posting a helpful script.
> >
> > I haven't kept up on perl packages, but I recall
Jan Wieck <[EMAIL PROTECTED]> writes:
>> backend start/stop events probably need to be reported whenever the
>> postmaster variable is set, even if all the USERSET variables are off.
> I don't consider backend start/stop messages to be critical,
> although we get some complaints alrea
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> If somebody wants to see an applications querystring (at
>> least the first 512 bytes) just in case something goes wrong
>> and the client hangs, he'd have to run querystring reporting
>> all the time either way.
> Agreed. That should be on all
Jan Wieck <[EMAIL PROTECTED]> writes:
> So I can see value in a per database default in pg_database
> plus the ability to switch it on/off via statement to analyze
> single commands.
Do you even need a per-database default? Why not an installation-wide
default in postgresql.conf pl
