Hi,
On Tue, May 5, 2009 at 2:37 AM, K, Niranjan (NSN - IN/Bangalore)
wrote:
> Hi,
>
> This is to support an admin command or utility which can trigger the
> server to be taken to a standalone mode if there a connection failure
> detection between Primary and server. It need not be always, that th
I found out at PGCon that the internal format of tsvector changed
slightly from 8.3 to 8.4. Teodor gave me a conversion function and I
have adjusted pg_migrator to install a v8_3_tsvector data type to be
used during the load so the old user tables use that data type. You can
see the code here at
On Mon, May 25, 2009 at 8:03 PM, Tom Lane wrote:
> Greg Stark writes:
>> On Mon, May 25, 2009 at 11:32 PM, Tom Lane wrote:
>>> Admittedly this is a bit inconvenient, but the point is that the
>>> functionality does exist. There is no need to have a built-in
>>> version of this function unless w
On Mon, May 25, 2009 at 6:15 PM, Tom Lane wrote:
> Now I'm still not exactly happy with GEQO, but it's surely a lot better
> than it was in the fall of 2000. So on the whole it does seem that the
> current relationships between from_collapse_limit, join_collapse_limit,
> and geqo_threshold are ba
That would be more work, not less, for the known existing users of the
function (namely pg_dump and psql). It's a bit late to be redesigning
the function's API anyway.
I agree.
The recommended way to do that is to use pg_get_expr --- it'd certainly
be a bad idea to try to parse that string f
On 26/05/2009, at 10:25 AM, Tom Lane wrote:
Andrew McNamara writes:
Are there any other cases where the binary receive functions are
missing sanity checks?
Possibly --- you want to go looking?
Uh. I'd be lying if I said I "wanted to" - I got enough of a taste of
those functions when tryi
Andrew McNamara writes:
> Are there any other cases where the binary receive functions are
> missing sanity checks?
Possibly --- you want to go looking?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your sub
On 26/05/2009, at 5:41 AM, Tom Lane wrote:
The only place I can find where an oversize time value behaves in a
seriously bogus fashion is in time_out, or more specifically
EncodeTimeOnly(): it fails to initialize its output string at all.
So you could easily get garbage text output, though in m
Greg Stark writes:
> On Mon, May 25, 2009 at 11:32 PM, Tom Lane wrote:
>> Admittedly this is a bit inconvenient, but the point is that the
>> functionality does exist. There is no need to have a built-in
>> version of this function unless we get significant advantages
>> from having it built-in,
Gevik Babakhani writes:
> Perhaps it would be much better if pg_get_function_arguments returned
> the data is some kind of a structure than a blob of string like the above.
That would be more work, not less, for the known existing users of the
function (namely pg_dump and psql). It's a bit late
On Mon, May 25, 2009 at 11:32 PM, Tom Lane wrote:
> Admittedly this is a bit inconvenient, but the point is that the
> functionality does exist. There is no need to have a built-in
> version of this function unless we get significant advantages
> from having it built-in, and right now I'm not see
On Mon, May 25, 2009 at 6:32 PM, Tom Lane wrote:
> Robert Haas writes:
>> I agree with this, but there is a lot of sentiment (which I share)
>> that it should be possible to capture EXPLAIN output using subselect
>> or CTAS syntax, regardless of exactly what that output ends up being.
>
> Well, i
I am trying to extract function argument information using the
pg_get_function_arguments() and it strikes me that despite of this
function generating very useful information, it is actually not so user
friendly.
Consider the following:
-
create o
Robert Haas writes:
> I agree with this, but there is a lot of sentiment (which I share)
> that it should be possible to capture EXPLAIN output using subselect
> or CTAS syntax, regardless of exactly what that output ends up being.
Well, it should be possible to capture the output, but let's not
Robert Haas writes:
> On Thu, May 21, 2009 at 7:50 AM, Tom Lane wrote:
>> Josh Berkus writes:
>>> ... trying to remember why I wrote that ... what would happen if
>>> FROM_COLLAPSE_LIMIT was *more* than GEQO_THRESHOLD?
>>
>> I think I wrote it, not you. The point of the advice is to keep
>> su
On Mon, May 25, 2009 at 11:22 AM, Tom Lane wrote:
> Joshua Tolley writes:
>> I'm not sure I see why it would be less flexible. I'm imagining we define
>> some
>> record type, and a function that returns a set of those records.
>
> I'm unimpressed by the various proposals to change EXPLAIN into a
Hi Tom,
On 05/25/2009 08:04 PM, Tom Raney wrote:
So, why not put ALL interesting data in the EXPLAIN XML feed? I'm not
suggesting for this discussion that we include discarded plans, but that
we include every piece of data that may be of interest to folks building
connecting tools. The parsers c
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I'm not entirely sure why we put a range limit on time values at all,
>> but given that we do, it'd probably be a good idea to check the range
>> in the recv functions. I'm inclined to fix this for 8.4, but not
>> back-patch becaus
Peter Eisentraut writes:
> On Sunday 26 April 2009 21:29:20 Tom Lane wrote:
>> This is bogus: errmsg expects that it should itself feed its first
>> argument through gettext(), not receive an argument that is already
>> translated. That's at the least a waste of cycles, and it's not
>> entirely i
On Mon, May 25, 2009 at 11:22:24AM -0400, Tom Lane wrote:
> Joshua Tolley writes:
> > I'm not sure I see why it would be less flexible. I'm imagining we define
> > some
> > record type, and a function that returns a set of those records.
>
> I'm unimpressed by the various proposals to change EXP
On May 25, 2009, at 0:47 , Joshua Tolley wrote:
On Sun, May 24, 2009 at 06:53:29PM -0400, Tom Lane wrote:
Greg Smith writes:
On Sun, 24 May 2009, Pavel Stehule wrote:
we should have a secondary function explain_query(query_string,
option) that returns setof some.
+1. The incremental appr
David Fetter wrote:
On Mon, May 25, 2009 at 11:02:53AM -0400, Tom Lane wrote:
Robert Haas writes:
This is all much more complicated than what I proposed, and I fail
to see what it buys us. I'd say that you're just reinforcing the
point I made upthread, which is that insisting that XML
Andres Freund writes:
>> You can define that a subset (or all) files use a specific "diff driver"
>> in the repository - unfortunately the definition of that driver has to
>> be done locally. Defining it currently involves installing a wrapper
>> like the one on http://wiki.postgresql.org/wiki/Tal
On 05/25/2009 07:53 PM, Andres Freund wrote:
On 05/25/2009 07:31 PM, Tom Lane wrote:
David Fetter writes:
On Mon, May 25, 2009 at 12:24:05PM -0400, Tom Lane wrote:
If you'd like to accomplish something *useful* about this, how about
pestering git upstream to support diff -c output format?
I
On 05/25/2009 07:31 PM, Tom Lane wrote:
David Fetter writes:
On Mon, May 25, 2009 at 12:24:05PM -0400, Tom Lane wrote:
If you'd like to accomplish something *useful* about this, how about
pestering git upstream to support diff -c output format?
It looks like this is doable with a suitable g
On 05/25/2009 07:20 PM, Alvaro Herrera wrote:
David Fetter wrote:
On Mon, May 25, 2009 at 12:24:05PM -0400, Tom Lane wrote:
If you'd like to accomplish something *useful* about this, how about
pestering git upstream to support diff -c output format?
It looks like this is doable with a suitabl
David Fetter writes:
> On Mon, May 25, 2009 at 12:24:05PM -0400, Tom Lane wrote:
>> If you'd like to accomplish something *useful* about this, how about
>> pestering git upstream to support diff -c output format?
> It looks like this is doable with a suitable git configuration file
> such as $HOM
David Fetter wrote:
> On Mon, May 25, 2009 at 12:24:05PM -0400, Tom Lane wrote:
> > If you'd like to accomplish something *useful* about this, how about
> > pestering git upstream to support diff -c output format?
>
> It looks like this is doable with a suitable git configuration file
> such as $H
Michael Meskes writes:
> On Mon, May 25, 2009 at 12:10:49PM -0400, Tom Lane wrote:
>> Consider
>>
>> if (...)
>> macro;
>> else
>> something-else;
> Sure, but some/most/all macros are called as
> MACRO;
> No real reason there it seems.
Well, they are calle
Zdenek Kotala writes:
> Tom Lane pÃÅ¡e v ne 24. 05. 2009 v 18:46 -0400:
>> In any case, the barriers to implementing 8.3-style hash indexes in 8.4
>> are pretty huge: you'd need to duplicate not only the hash AM code, but
>> also all the hash functions, and therefore all of the hash pg_amop and
>
Hello Fujii,
my name is Harald Kolb, I'm a colleague of Niranjan and I will continue
his community work since he's currently busy with other topics.
We are looking for a fast mechanism to activate the switchover. Therfore
we prefer to use a signal to trigger the standby to become primary,
since in
On Mon, May 25, 2009 at 12:10:49PM -0400, Tom Lane wrote:
> Consider
>
> if (...)
> macro;
> else
> something-else;
> ...
Sure, but some/most/all macros are called as
MACRO;
No real reason there it seems.
> [ thinks for a bit... ] What might be both sa
On Mon, May 25, 2009 at 12:24:05PM -0400, Tom Lane wrote:
> If you'd like to accomplish something *useful* about this, how about
> pestering git upstream to support diff -c output format?
It looks like this is doable with a suitable git configuration file
such as $HOME/.gitconfig or (finer grain)
On Mon, May 25, 2009 at 12:24:05PM -0400, Tom Lane wrote:
> David Fetter writes:
> > On Mon, May 25, 2009 at 11:45:33AM -0400, Stephen Frost wrote:
> >> I'm all for moving to git, but not until at least the core folks are
> >> more familiar with it and have been using it.
>
> > Which ones aren't
David Fetter writes:
> On Mon, May 25, 2009 at 11:45:33AM -0400, Stephen Frost wrote:
>> I'm all for moving to git, but not until at least the core folks are
>> more familiar with it and have been using it.
> Which ones aren't familiar and haven't been using it for at least the
> past year? I co
Michael Meskes writes:
> On Mon, May 25, 2009 at 11:27:27AM -0400, Tom Lane wrote:
>> You can't just remove the "else", or it's unsafe;
> But why? What does this empty else accomplish?
Consider
if (...)
macro;
else
something-else;
Without the "el
I tried to run msgfmt -v ... on solaris and I got following error:
Processing file "psql-cs.po"...
GNU PO file found.
Generating the MO file in the GNU MO format.
Processing file "psql-cs.po"...
Lines 1311, 1312 (psql-cs.po): incompatible printf-format.
0 format specifier(s) in "msgid", but 1
David Fetter wrote:
On Mon, May 25, 2009 at 09:59:14AM -0400, Tom Lane wrote:
Dimitri Fontaine writes:
Tom Lane writes:
The rearrangement might be marginally nicer from a code
beautification point of view --- right now we're a bit
inconsistent about whether datatype-specific
On Mon, May 25, 2009 at 11:45:33AM -0400, Stephen Frost wrote:
> David,
>
> * David Fetter (da...@fetter.org) wrote:
> > It's pretty relevant as far as the schedule goes. I'm not alone
> > thinking that the appropriate place to make this change, given
> > buildfarm support, is at the transition t
On Mon, May 25, 2009 at 11:27:27AM -0400, Tom Lane wrote:
> Oh, right, that was Bruce's "improvement" of the COPY code. I was less
> than thrilled with it, but didn't have an easy alternative.
>
> You can't just remove the "else", or it's unsafe; and I'm afraid that
But why? What does this empty
David,
* David Fetter (da...@fetter.org) wrote:
> It's pretty relevant as far as the schedule goes. I'm not alone
> thinking that the appropriate place to make this change, given
> buildfarm support, is at the transition to 8.5.
>
> CVS is dead. Long live git! :)
I'm all for moving to git, but
Tom Lane píše v ne 24. 05. 2009 v 18:46 -0400:
> Kenneth Marshall writes:
> > On Sat, May 23, 2009 at 02:52:49PM -0400, Zdenek Kotala wrote:
> >>> Attached patch cleanups hash index headers to allow compile hasham for
> >>> 8.3 version. It helps to improve pg_migrator with capability to migrate
>
On Mon, May 25, 2009 at 09:59:14AM -0400, Tom Lane wrote:
> Dimitri Fontaine writes:
> > Tom Lane writes:
> >> The rearrangement might be marginally nicer from a code
> >> beautification point of view --- right now we're a bit
> >> inconsistent about whether datatype-specific hash functions live
On Mon, May 25, 2009 at 11:02:53AM -0400, Tom Lane wrote:
> Robert Haas writes:
> > This is all much more complicated than what I proposed, and I fail
> > to see what it buys us. I'd say that you're just reinforcing the
> > point I made upthread, which is that insisting that XML is the
> > only w
Michael Meskes writes:
> On Mon, May 25, 2009 at 10:19:40AM -0400, Tom Lane wrote:
>> That sounds both dangerous and against our coding conventions. The
>> standard way to do that is "do { ... } while (0)"
> Which won't work here as the macros have continue and break commands in them.
Oh, right
Joshua Tolley writes:
> I'm not sure I see why it would be less flexible. I'm imagining we define some
> record type, and a function that returns a set of those records.
I'm unimpressed by the various proposals to change EXPLAIN into a
function. Quoting the command-to-explain is going to be a pa
On Mon, May 25, 2009 at 10:19:40AM -0400, Tom Lane wrote:
> Michael Meskes writes:
> > - some combination of signed and unsigned: ~ 600
> > Are we really sure that *all* compilers out there do handle this
> > correctly?
>
> The behavior is spelled out in the C spec, and always has been. You
>
> The impression I have is that (to misquote Churchill) XML is the worst
> option available, except for all the others. We need something that can
> represent a fairly complex data structure, easily supports addition or
> removal of particular fields in the structure (including fields not
> forese
On Mon, May 25, 2009 at 10:55:48AM -0400, Tom Lane wrote:
> Joshua Tolley writes:
> > The Oracle version, as it fills the table of explain results, gives
> > each number an id and the id of its parent row, which behavior we
> > could presumably copy. I'm definitely keen to keep a human-readable
>
Robert Haas writes:
> This is all much more complicated than what I proposed, and I fail to
> see what it buys us. I'd say that you're just reinforcing the point I
> made upthread, which is that insisting that XML is the only way to get
> more detailed information will just create a cottage indus
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I'm not entirely sure why we put a range limit on time values at all,
> but given that we do, it'd probably be a good idea to check the range
> in the recv functions. I'm inclined to fix this for 8.4, but not
> back-patch because of compatibility considerat
On Mon, May 25, 2009 at 07:14:56AM -0400, Robert Haas wrote:
> Many people who responded to this
> thread were fine with the idea of some sort of options syntax, but we
> had at least four different proposals for how to implement it:
>
> Robert Haas: EXPLAIN (foo 'bar', baz 'bletch', ...) query
>
Joshua Tolley writes:
> The Oracle version, as it fills the table of explain results, gives
> each number an id and the id of its parent row, which behavior we
> could presumably copy. I'm definitely keen to keep a human-readable
> EXPLAIN such as we have now, to augment the table-based proposal,
Andrew McNamara writes:
> When submitting a query via the V3 binary protocol (PQexecParams,
> paramFormats[n]=1), it appears the PostgreSQL server performs no range
> checking on the passed values.
A quick look at time_recv() shows this is true, and timetz_recv()
checks neither the time nor t
Peter Eisentraut píše v ne 24. 05. 2009 v 00:40 +0300:
> I think this is not the best way to do it, because it will confuse pgindent
> and editors and such. The DATA() macros in include/catalog have this solved;
> see include/catalog/genbki.sh.
Attached variant with faked extern without ; whi
Michael Meskes writes:
> - some combination of signed and unsigned: ~ 600
> Are we really sure that *all* compilers out there do handle this correctly?
The behavior is spelled out in the C spec, and always has been. You
might as well worry if they handle "if" correctly.
> There are some #de
On May 25, 2009, at 9:41 AM, jibin jose wrote:
which tool is used as profiler in postgresql
There is some code in the backend to support gprof; I know that some
people have had good luck with oprofile, too, which doesn't require
any special support.
...Robert
--
Sent via pgsql-hackers
which tool is used as profiler in postgresql
Dimitri Fontaine writes:
> Tom Lane writes:
>> The rearrangement might be marginally nicer from a code beautification
>> point of view --- right now we're a bit inconsistent about whether
>> datatype-specific hash functions live in hashfunc.c or in the datatype's
>> utils/adt/ file. But I'm not
Dimitri Fontaine writes:
> And currently calling SPI_connect() from _PG_init will crash the
> backend. I'll try to obtain a gdb backtrace, I've just been told about
> pre_auth_delay and post_auth_delay parameters.
Here we go:
(gdb) handle SIGABRT nopass
SignalStop Print Pass to pr
Hi,
Tom Lane writes:
> The rearrangement might be marginally nicer from a code beautification
> point of view --- right now we're a bit inconsistent about whether
> datatype-specific hash functions live in hashfunc.c or in the datatype's
> utils/adt/ file. But I'm not sure that removing hashfunc
Hi,
On Mon, May 25, 2009 at 7:10 PM, Kolb, Harald (NSN - DE/Munich)
wrote:
> Hello Fujii,
>
> my name is Harald Kolb, I'm a colleague of Niranjan and I will continue
> his community work since he's currently busy with other topics.
> We are looking for a fast mechanism to activate the switchover.
2009/5/25 Martijn van Oosterhout :
> On Mon, May 25, 2009 at 01:20:05PM +0200, Pavel Stehule wrote:
>> Hello
>>
>> I can't to find fine syntax for cyclic declaration:
>
> If you mean forward declaraions of a type, just:
>
> struct ParseState
>
> will do, then:
>
>> typedef Node *(*TransformColumnRe
On Mon, May 25, 2009 at 01:20:05PM +0200, Pavel Stehule wrote:
> Hello
>
> I can't to find fine syntax for cyclic declaration:
If you mean forward declaraions of a type, just:
struct ParseState
will do, then:
> typedef Node *(*TransformColumnRef_hook_type) (struct ParseState *pstate,
> ColumnR
Hello
I can't to find fine syntax for cyclic declaration:
.
typedef Node *(*TransformColumnRef_hook_type) (ParseState *pstate,
ColumnRef *cref);
typedef struct ParseState
{
struct ParseState *parentParseState;/* stack link */
const char *p_sourcetext; /* source
On Mon, May 25, 2009 at 6:24 AM, Dimitri Fontaine
wrote:
> I think the summary here is to say that we want two modes of operations:
> - the current one, which continues to get refinements
>
> - a new one conveying all possible information in machine readable
> formats, possibly with some tools
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[Sent by mistake to Robert Haas only at first try. No cure for fat
fingers, I guess]
On Sun, May 24, 2009 at 04:05:18PM -0400, Robert Haas wrote:
[...]
> I think XML output format is a complete distraction from the real
> issue here, which is that t
Hi,
After having read all the followups I already received, I prefer to
answer to this particular message.
Robert Haas writes:
> On Sun, May 24, 2009 at 3:09 PM, Tom Lane wrote:
>> On the other side of the coin, I'm strongly against inventing more than
>> one new output format for EXPLAIN, and
2009/5/25 Pavel Stehule :
> 2009/5/24 Tom Lane :
>> Pavel Stehule writes:
>>> ==Steps==
>>> 1. add hook to analyser (transform stage) to substitute unknown
>>> columnref by param - when analyser detect unknown columnref, then call
>>> callback, that returns possible para node or NULL (when externa
Hi,
sitting here on my flight back I went through the list of all warnings gcc
spits out when using -Wextra. There are a whole lot of them (~ 1700) that
mostly (except one) fall into one of four classes:
- unused parameters: ~ 600
- some combination of signed and unsigned: ~ 600
Are we really s
Hi,
Preliminary note: I'm using the term "extension" as if it's what we
already agree to call them, feel free to ignore this and use whatever
term you see fit. We'll have the naming issue tackled, please not now
though.
Following-up to discussions we had at the Developer Meeting and
subse
71 matches
Mail list logo
