Anyway it seems like this whole area is a research project for 8.4
or later, not something we should try to fix now. But having said
that, there didn't seem to be any objection to the idea of changing
the outer block (where function parameters are declared) to be labeled
with the function name, i
I wrote:
> ... In at least those three cases, we know that it's not sensible to
> substitute a parameter. If that's true in all the problem cases,
> which seems likely, then we could do something with Greg's idea
> of using the raw parse tree from the main SQL parser to guide
> decisions about whe
Tom Lane wrote:
I suspect that error messages coming out of the syslogger itself (and
directed to the original stderr destination) will be similarly broken.
I thought we had that case handled, but I could be wrong.
So that patch still needs work.
Yes, darnit.
I think we probably need
Chris Browne <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>>> animal: grebe warnings: 45
>>> xlog.c:651: warning: implicit declaration of function '_check_lock'
>>> xlog.c:654: warning: implicit declaration of function '_clear_lock'
>>> hba.c:1449: warning: implicit declaration of fu
Martin Pihlak <[EMAIL PROTECTED]> writes:
> I'm working on a patch to extend the stats collector to handle stored
> procedure
> statistics (call counts, duration etc).
> ...
> Only functions with oid >= FirstNormalObjectId are accounted.
I really dislike that approach to deciding which functions
[ ok, let's try this again --- apparently there's something in my mail
software that dislikes embedded nulls ]
I was experimenting with what happened if I made the pg_log directory
unwritable, and found out that this comes out on stderr:
_J3tFATAL: could not create log file
"pg_log/postgresql-2
I was experimenting with what happened if I made the pg_log directory
unwritable, and found out that this comes out on stderr:
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> Anyway, I tweaked plpgsql's Makefile to force LC_CTYPE=3DC, which
>> theoretically should silence this warning.
> This doesn't mean that people were previousy able to use any of these "exot=
> ic"
> characters li
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> and this is the initial list for contrib(excluding a lot of duplicate
> warnings and stuff that is a result of invalid compiler flags which I
> will mention seperatly):
I fixed most of these, I believe. A couple remain untouched:
> animal: cucko
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Anyway, I tweaked plpgsql's Makefile to force LC_CTYPE=C, which
> theoretically should silence this warning.
This doesn't mean that people were previousy able to use any of these "exotic"
characters like aßertion or explaïn if they happened to compile in t
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> What I suspect is happening is that lionfish is running the buildfarm
>> script in a non-C locale, in which flex finds that some high-bit-set
>> characters are case-folded by tolower() and accordingly issues this
>> complaint. N
On Sat, 2007-07-14 at 19:52 -0400, Tom Lane wrote:
> "Affan Salman" <[EMAIL PROTECTED]> writes:
> > Could we not, at least, support explicit column disambiguation?
>
> The problem is that there are places in the SQL grammar where we don't
> allow qualification of a SQL name --- INSERT column lists
Zdenek Kotala wrote:
> Stefan Kaltenbrunner wrote:
>> Zdenek Kotala wrote:
>
>>> For sun studio -erroff=E_STATEMENT_NOT_REACHED is useful there. If you
>>> want to determine warning tags for each warning add -errtags.
>>
>> Is that supported on all versions of sun studio(Sun WorkShop 6, Sun
>> Stu
Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
We ran into a problem with a customer this weekend. They had >128,000
tables and we were trying to run a pg_dump. When we reached
max_locks_per_transaction, the dump just hung waiting to lock the next
table.
Would it make sense t
14 matches
Mail list logo