Tom Lane wrote:
Craig Ringer <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Craig Ringer <[EMAIL PROTECTED]> writes:
Speaking of this sort of support tool, what I personally often wish for
is unique error message identifiers that can be looked up (say, with a
web form) or a way to
Craig Ringer <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Craig Ringer <[EMAIL PROTECTED]> writes:
>>> Speaking of this sort of support tool, what I personally often wish for
>>> is unique error message identifiers that can be looked up (say, with a
>>> web form) or a way to un/re-translate l
Tom Lane wrote:
Craig Ringer <[EMAIL PROTECTED]> writes:
Speaking of this sort of support tool, what I personally often wish for
is unique error message identifiers that can be looked up (say, with a
web form) or a way to un/re-translate localized messages.
The VERBOSE option already
Craig Ringer <[EMAIL PROTECTED]> writes:
> Speaking of this sort of support tool, what I personally often wish for
> is unique error message identifiers that can be looked up (say, with a
> web form) or a way to un/re-translate localized messages.
The VERBOSE option already gives an exact pointe
Craig Ringer wrote:
> Simon Riggs wrote:
>
>> Obfuscating the names would make the code harder to understand, true,
>> but only if the code is written in English (or your language-of-choice).
>> It wouldn't damage our ability to read other language code at all.
>
> Speaking of this sort of support
Simon Riggs wrote:
Obfuscating the names would make the code harder to understand, true,
but only if the code is written in English (or your language-of-choice).
It wouldn't damage our ability to read other language code at all.
Speaking of this sort of support tool, what I personally often wi
On Thu, 2008-04-17 at 12:41 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Thu, 2008-04-17 at 12:12 -0400, Tom Lane wrote:
> >> Aren't these suggestions mutually contradictory?
>
> > No, they're orthogonal. The pretty printer would get the indenting and
> > line feeds corr
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Thu, 2008-04-17 at 12:12 -0400, Tom Lane wrote:
>> Aren't these suggestions mutually contradictory?
> No, they're orthogonal. The pretty printer would get the indenting and
> line feeds correct, the obfuscator would replace actual names with "A",
> "B"
On Thu, 2008-04-17 at 12:12 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > I think it would help if there was some way to prepare functions to
> > allow them to be posted and understood more easily. These would help:
>
> > * a name obfuscator, so people can post functions wit
Simon Riggs <[EMAIL PROTECTED]> writes:
> I think it would help if there was some way to prepare functions to
> allow them to be posted and understood more easily. These would help:
> * a name obfuscator, so people can post functions without revealing
> inner workings of their company and potentia
On Wed, 2008-04-16 at 11:09 -0400, Tom Lane wrote:
> "Gavin M. Roy" <[EMAIL PROTECTED]> writes:
> > In 8.3.0, I'm seeing some oddities with SQL functions which I thought were
> > immune to the planner data restrictions of plpgsql functions and the sort.
>
> Without a specific example this discussi
"Gavin M. Roy" <[EMAIL PROTECTED]> writes:
> After detailed examination of pg_stat_user_indexes usage, it's clear that
> the functions don't use the same indexes. I've casted everything to match
> the indexes in the SQL function, to no success. Any suggestions on next
> steps? Maybe for 8.4 we c
On Wed, 16 Apr 2008 14:44:40 -0400
"Gavin M. Roy" <[EMAIL PROTECTED]> wrote:
> After detailed examination of pg_stat_user_indexes usage, it's clear
> that the functions don't use the same indexes. I've casted
> everything to match the indexes in the SQL function, to no success.
> Any suggestions
After detailed examination of pg_stat_user_indexes usage, it's clear that
the functions don't use the same indexes. I've casted everything to match
the indexes in the SQL function, to no success. Any suggestions on next
steps? Maybe for 8.4 we could find a way to explain analyze function
interna
Are you going to post the function? :-)
My PL/PGSQL functions are running fine in 8.3.x.
Cheers,
mark
Gavin M. Roy wrote:
In 8.3.0, I'm seeing some oddities with SQL functions which I thought
were immune to the planner data restrictions of plpgsql functions and
the sort. Basically I have a
"Gavin M. Roy" <[EMAIL PROTECTED]> writes:
> In 8.3.0, I'm seeing some oddities with SQL functions which I thought were
> immune to the planner data restrictions of plpgsql functions and the sort.
Without a specific example this discussion is pretty content-free, but
in general SQL functions face
16 matches
Mail list logo
