Hey Magnus, what exactly was your process for verifying the file
contents of the various release tags in the git conversion? Did
you check them against the published tarballs, or against what the
CVS repository said they should be? Because I've just found that
this odd-looking manufactured commit
Peter Eisentraut wrote:
On tor, 2010-09-09 at 13:08 -0700, Darren Duncan wrote:
Since Pg's FUNCTION already seems to take on both roles, so
overloading the meaning of the FUNCTION keyword, like what a C
function or a Perl sub does, where returning VOID means procedure,
then what is being added b
On tor, 2010-09-09 at 16:16 -0400, Tom Lane wrote:
> You might care to go back and re-read some of the extensive prior
> threads about this, but to my mind the main thing that would justify
> inventing a separate PROCEDURE facility is if procedures were to
> execute outside the transaction system,
On tor, 2010-09-09 at 13:08 -0700, Darren Duncan wrote:
> Since Pg's FUNCTION already seems to take on both roles, so
> overloading the meaning of the FUNCTION keyword, like what a C
> function or a Perl sub does, where returning VOID means procedure,
> then what is being added by a distinct PROCED
On Fri, Sep 10, 2010 at 11:52 AM, Fujii Masao wrote:
> The attached patch implements the above and simple synchronous replication
> feature, which doesn't include quorum commit capability. The replication
> mode (async, recv, fsync, replay) can be specified on a per-standby basis,
> in standbys.co
Robert Haas wrote:
> On Thu, Sep 9, 2010 at 3:28 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> We certainly now have MANY documented field complaints at least of the
> >> exit-128-on-Windows problem, if not the more general
> >> backend-exits-without-going-through-the-normal-cleanup-path probl
2010/9/7 Teodor Sigaev :
>> AFAICS, these patches include no documentation. That's pretty much a
>> fatal flaw for a feature of this magnitude. At an absolute minimum,
>> you need to update the system catalog documentation and the
>> documentation on CREATE / ALTER OPERATOR CLASS. There might be
2010/9/9 Darren Duncan :
> Kevin Grittner wrote:
>>
>> Tom Lane wrote:
>>>
>>> to my mind the main thing that would justify inventing a separate
>>> PROCEDURE facility is if procedures were to execute outside the
>>> transaction system, so that they could start and stop transactions
>>> for themse
Tom Lane wrote:
One point that has to be made is that returning multiple result sets
as if they were successive queries restricts the client to reading the
result sets serially; that is, you must read all of result A before you
can look at result B, etc.
One aspect that I don't really like abou
2010/9/9 Kevin Grittner :
> Tom Lane wrote:
>
>> I'm with Robert: this would be a huge extra complication for a
>> remarkably small amount of benefit.
>
> This is probably heresy, but unless it's required by the standard or
> drop-dead simple to allow, I'd be fine with *not* supporting
> overloadi
2010/9/9 Tom Lane :
> Pavel Stehule writes:
>> 2010/9/9 Robert Haas :
>>> That seems like a lot of complexity for no real benefit, to me.
>
>> no, you can to specify a expected result type - it's very for some
>> convert or import functions. So we expect so out procedures will
>> supports to OUT
Tom Lane wrote:
> I'm with Robert: this would be a huge extra complication for a
> remarkably small amount of benefit.
This is probably heresy, but unless it's required by the standard or
drop-dead simple to allow, I'd be fine with *not* supporting
overloading of stored procedure names based o
Pavel Stehule writes:
> 2010/9/9 Robert Haas :
>> That seems like a lot of complexity for no real benefit, to me.
> no, you can to specify a expected result type - it's very for some
> convert or import functions. So we expect so out procedures will
> supports to OUT parameters, then implementat
Kevin Grittner wrote:
Tom Lane wrote:
to my mind the main thing that would justify inventing a separate
PROCEDURE facility is if procedures were to execute outside the
transaction system, so that they could start and stop transactions
for themselves.
That is the biggest distinction in my mind
Tom Lane wrote:
> I don't understand the point of a RETURN value when there can be
> no caller to return a value to.
The version of the draft standard I last saw allowed something like:
SET x = CALL sp(param_a, param_b);
I seem to remember Sybase supported a return value as well as OUT
par
Robert Haas writes:
> To be honest, I am already pretty unhappy with
> the changes that make it impossible to redefined foo(a int) as
> foo(anteater int), which is a perfectly reasonable thing to want to do
> but which is now forbidden because someone MIGHT have called the
> function as foo(a := 3
2010/9/9 Robert Haas :
> On Thu, Sep 9, 2010 at 4:29 PM, Pavel Stehule wrote:
so I can to write
CREATE PROCEDURE foo(OUT a int)
...
and
CREATE PROCEDURE foo(OUT a varchar)
...
and then when I use a statement CALL is correct procedure selected
"Kevin Grittner" writes:
> Tom Lane wrote:
>> to my mind the main thing that would justify inventing a separate
>> PROCEDURE facility is if procedures were to execute outside the
>> transaction system, so that they could start and stop transactions
>> for themselves.
> That is the biggest disti
2010/9/9 Robert Haas :
> On Thu, Sep 9, 2010 at 4:29 PM, Pavel Stehule wrote:
so I can to write
CREATE PROCEDURE foo(OUT a int)
...
and
CREATE PROCEDURE foo(OUT a varchar)
...
and then when I use a statement CALL is correct procedure selected
On Thu, Sep 9, 2010 at 4:29 PM, Pavel Stehule wrote:
>>> so I can to write
>>>
>>> CREATE PROCEDURE foo(OUT a int)
>>> ...
>>>
>>> and
>>> CREATE PROCEDURE foo(OUT a varchar)
>>> ...
>>>
>>> and then when I use a statement CALL is correct procedure selected
>>>
>>> CALL foo(textvariable)
>>
>> Tha
2010/9/9 Darren Duncan :
> Tom Lane wrote:
>>
>> Darren Duncan writes:
>>>
>>> Since Pg's FUNCTION already seems to take on both roles, so overloading
>>> the meaning of the FUNCTION keyword, like what a C function or a Perl sub
>>> does, where returning VOID means procedure, then what is being ad
Tom Lane wrote:
Darren Duncan writes:
Since Pg's FUNCTION already seems to take on both roles, so overloading the
meaning of the FUNCTION keyword, like what a C function or a Perl sub does,
where returning VOID means procedure, then what is being added by a distinct
PROCEDURE?
You might car
2010/9/9 Robert Haas :
> On Thu, Sep 9, 2010 at 4:17 PM, Pavel Stehule wrote:
>> 2010/9/9 Darren Duncan :
>>> Pavel Stehule wrote:
there are lot of questions - and I am not sure if procedures
implementation can be done in one release cycle. The basic questions:
* should be
Tom Lane wrote:
> to my mind the main thing that would justify inventing a separate
> PROCEDURE facility is if procedures were to execute outside the
> transaction system, so that they could start and stop transactions
> for themselves.
That is the biggest distinction in my mind, too. Support
2010/9/9 Tom Lane :
> Darren Duncan writes:
>> Since Pg's FUNCTION already seems to take on both roles, so overloading the
>> meaning of the FUNCTION keyword, like what a C function or a Perl sub does,
>> where returning VOID means procedure, then what is being added by a distinct
>> PROCEDURE?
>
On Thu, Sep 9, 2010 at 4:17 PM, Pavel Stehule wrote:
> 2010/9/9 Darren Duncan :
>> Pavel Stehule wrote:
>>>
>>> there are lot of questions - and I am not sure if procedures
>>> implementation can be done in one release cycle. The basic questions:
>>>
>>> * should be special catalog for procedures
2010/9/9 Darren Duncan :
> Pavel Stehule wrote:
>>
>> there are lot of questions - and I am not sure if procedures
>> implementation can be done in one release cycle. The basic questions:
>>
>> * should be special catalog for procedures or we will use pg_proc?
>> * how can be implemented OUT variab
Darren Duncan writes:
> Since Pg's FUNCTION already seems to take on both roles, so overloading the
> meaning of the FUNCTION keyword, like what a C function or a Perl sub does,
> where returning VOID means procedure, then what is being added by a distinct
> PROCEDURE?
You might care to go bac
On Thu, Sep 9, 2010 at 22:09, Tom Lane wrote:
> Robert Haas writes:
>> It's hard to say what the safest option is, I think. There seem to be
>> basically three proposals on the table:
>
>> 1. Back-port the dead-man switch, and ignore exit 128.
>> 2. Don't back-port the dead-man switch, but ignor
Robert Haas writes:
> It's hard to say what the safest option is, I think. There seem to be
> basically three proposals on the table:
> 1. Back-port the dead-man switch, and ignore exit 128.
> 2. Don't back-port the dead-man switch, but ignore exit 128 anyway.
> 3. Revert to Magnus's original so
Pavel Stehule wrote:
there are lot of questions - and I am not sure if procedures
implementation can be done in one release cycle. The basic questions:
* should be special catalog for procedures or we will use pg_proc?
* how can be implemented OUT variables - the original implementation
is simpl
On Thu, Sep 9, 2010 at 3:28 PM, Tom Lane wrote:
> Robert Haas writes:
>> We certainly now have MANY documented field complaints at least of the
>> exit-128-on-Windows problem, if not the more general
>> backend-exits-without-going-through-the-normal-cleanup-path problem.
>
> Right, which is why I
Robert Haas writes:
> We certainly now have MANY documented field complaints at least of the
> exit-128-on-Windows problem, if not the more general
> backend-exits-without-going-through-the-normal-cleanup-path problem.
Right, which is why I still don't care to risk back-porting a fix for
the latt
On Thu, Sep 9, 2010 at 3:00 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Sep 9, 2010 at 2:23 PM, Tom Lane wrote:
>>> We're not so worried about this case that we'd want to backport the
>>> deadman switch into 8.3 or 8.2 to have a fix there, are we?
>
>> I think we should consider backpor
Magnus Hagander writes:
> On Thu, Sep 9, 2010 at 21:00, Tom Lane wrote:
>> The thrust of my question was more along the lines of whether we should
>> look for a different solution to the current problem, so that we would
>> have something that could be back-ported into 8.2 and 8.3. Personally
>>
On Thu, Sep 9, 2010 at 21:00, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Sep 9, 2010 at 2:23 PM, Tom Lane wrote:
>>> We're not so worried about this case that we'd want to backport the
>>> deadman switch into 8.3 or 8.2 to have a fix there, are we?
>
>> I think we should consider backporti
Robert Haas writes:
> On Thu, Sep 9, 2010 at 2:23 PM, Tom Lane wrote:
>> We're not so worried about this case that we'd want to backport the
>> deadman switch into 8.3 or 8.2 to have a fix there, are we?
> I think we should consider backporting the deadman switch to 8.3 and 8.2.
[ raised eyebro
2010/9/9 Alvaro Herrera :
> Excerpts from Pavel Stehule's message of jue sep 09 14:29:57 -0400 2010:
>
>> * how can be implemented OUT variables - the original implementation
>> is simple - it's just pointer, but it's not directly possible inside
>> postgres, because we use a MemoryContexts?
>
> Wh
Excerpts from Pavel Stehule's message of jue sep 09 14:29:57 -0400 2010:
> * how can be implemented OUT variables - the original implementation
> is simple - it's just pointer, but it's not directly possible inside
> postgres, because we use a MemoryContexts?
Why is this a problem? Just return a
2010/9/9 Tom Lane :
> Pavel Stehule writes:
>> 2010/9/9 David E. Wheeler :
>>> On Sep 9, 2010, at 12:12 AM, Pavel Stehule wrote:
about 2 months for full time and 2 months for partial time - is my tip
>>>
>>> Two months full or two months partial? I'll take the latter, please!
>
>> 2 months -
On Thu, Sep 9, 2010 at 2:23 PM, Tom Lane wrote:
> We're not so worried about this case that we'd want to backport the
> deadman switch into 8.3 or 8.2 to have a fix there, are we?
I think we should consider backporting the deadman switch to 8.3 and 8.2.
--
Robert Haas
EnterpriseDB: http://www.e
Magnus Hagander writes:
> On Thu, Sep 9, 2010 at 19:48, Tom Lane wrote:
>> On balance I think I'd suggest an #ifdef WIN32 in CleanupBackend that
>> made it accept 128 as a "normal exit" case.
> Seems reasonable. I'll whack it around for that - see attached.
Hm, still doesn't log, which I think
On Thu, Sep 9, 2010 at 19:48, Tom Lane wrote:
> Magnus Hagander writes:
>> On Tue, Aug 24, 2010 at 15:58, Tom Lane wrote:
>>> Given the existence of the deadman switch mechanism (which I hadn't
>>> remembered when this thread started), I'm coming around to the idea that
>>> we could just treat e
2010/9/9 Tom Lane :
> Pavel Stehule writes:
>> 2010/9/9 David E. Wheeler :
>>> On Sep 9, 2010, at 12:12 AM, Pavel Stehule wrote:
about 2 months for full time and 2 months for partial time - is my tip
>>>
>>> Two months full or two months partial? I'll take the latter, please!
>
>> 2 months -
Pavel Stehule writes:
> 2010/9/9 David E. Wheeler :
>> On Sep 9, 2010, at 12:12 AM, Pavel Stehule wrote:
>>> about 2 months for full time and 2 months for partial time - is my tip
>>
>> Two months full or two months partial? I'll take the latter, please!
> 2 months - basic implementation
> 1 mon
Magnus Hagander writes:
> On Tue, Aug 24, 2010 at 15:58, Tom Lane wrote:
>> Given the existence of the deadman switch mechanism (which I hadn't
>> remembered when this thread started), I'm coming around to the idea that
>> we could just treat exit(128) as nonfatal on Windows. If for some
>> reas
On Tue, Aug 24, 2010 at 15:58, Tom Lane wrote:
> Bruce Momjian writes:
>> Robert Haas wrote:
>>> Yeah, that seems very plausible, although exactly how to verify I don't
>>> know.
>
>> And here is confirmation from the Microsoft web site:
>
>> In some instances, calling GetExitCode() agains
2010/9/9 David E. Wheeler :
> On Sep 9, 2010, at 12:12 AM, Pavel Stehule wrote:
>
>> about 2 months for full time and 2 months for partial time - is my tip
>
> Two months full or two months partial? I'll take the latter, please!
2 months - basic implementation
1 months - cleaning and work on commi
On Sep 8, 2010, at 3:57 PM, Darren Duncan wrote:
>> While I don't agree with the idea of providing extra names that are
>> probably mostly going to increase the confusion of someone trying to
>> understand such a system, I think this use case would be well covered by
>> synonyms. But these would
On 09/08/2010 10:02 AM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Excerpts from Tom Lane's message of mié sep 08 12:12:31 -0400 2010:
>>> AFAIR it doesn't keep the first snapshot around. If it did, most of
>>> your work on snapshot list trimming would have been useless, no?
>
>> That's my poi
On Sep 9, 2010, at 12:12 AM, Pavel Stehule wrote:
> about 2 months for full time and 2 months for partial time - is my tip
Two months full or two months partial? I'll take the latter, please!
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your su
Hello
I am sending a updated version.
changes:
* tag %v removed from format function,
* proprietary tags %lq a iq removed from sprintf
* code cleaned
patch divided to two parts - format function and stringfunc (contains
sprintf function and substitute function)
Regards
Pavel Stehule
2010/9
On 09/08/2010 08:01 PM, Heikki Linnakangas wrote:
Yeah, there isn't much you can do about it. Perhaps you could set a
"mayday flag" (a global boolean variable) if it fails, and check that in
the main loop, elogging a warning there instead. But I don't think we
need to go to such lengths, realisti
On 09/08/2010 08:18 PM, Tom Lane wrote:
Considering that we know that major platforms
such as FreeBSD have changed their implementations *very* recently,
it seems foolish to assume that an executable built on a machine with
corrected pselect could not be run on one with an older implementation.
Hello
2010/9/9 John Adams :
> OK, how much are we talking about?
about 2 months for full time and 2 months for partial time - is my tip
depends on set of implemented features
regards
Pavel Stehule
>
> From: Josh Berkus
> To: John Adams
> Cc: PostgreSQL-devel
OK, how much are we talking about?
From: Josh Berkus
To: John Adams
Cc: PostgreSQL-development
Sent: Fri, September 3, 2010 1:07:03 PM
Subject: Re: [HACKERS] returning multiple result sets from a stored procedure
> I noticed in postgres you cannot return multi
56 matches
Mail list logo
