On 21 Nov 2009, at 02:56, Josh Berkus wrote:
Would a patch that changes that have any chance of being accepted? Or is
the gain (not having to repeat the DEFAULT clause, and being able to
maintain it at one place instead of many) considered too small compared
to the risk of breaking
Josh Berkus j...@agliodbs.com writes:
(2) this change, while very useful, does change what had been a simple
rule (All variables are NULL unless specifically set otherwise) into a
conditional one (All variables are NULL unless set otherwise OR unless
they are declared as domain types with
On Sat, Nov 21, 2009 at 7:26 AM, Josh Berkus j...@agliodbs.com wrote:
Would a patch that changes that have any chance of being accepted? Or is
the gain (not having to repeat the DEFAULT clause, and being able to
maintain it at one place instead of many) considered too small compared
to
Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
(2) this change, while very useful, does change what had been a
simple rule (All variables are NULL unless specifically set
otherwise) into a conditional one (All variables are NULL unless
set otherwise OR unless they are declared as domain
Gurjeet Singh wrote:
On Sat, Nov 21, 2009 at 7:26 AM, Josh Berkus j...@agliodbs.com
mailto:j...@agliodbs.com wrote: However, there are some other
issues to be resolved:
(1) what should be the interaction of DEFAULT parameters and domains
with defaults?
The function's DEFAULT parameter
On lör, 2009-11-21 at 22:20 +0100, Florian G. Pflug wrote:
I'm inclined to leave it alone. It complicates the mental model, and
frankly attaching defaults to domains was not one of the SQL
committee's better ideas anyway. It's *fundamentally*
non-orthogonal.
I've always though of
On Thu, Nov 19, 2009 at 9:06 PM, Florian G. Pflug f...@phlo.org wrote:
Hi
It seems that pl/pgsql ignores the DEFAULT value of domains for local
variables. With the following definitions in place
create domain myint as int default 0;
create or replace function myint() returns myint as $body$
Robert Haas wrote:
On Thu, Nov 19, 2009 at 9:06 PM, Florian G. Pflug f...@phlo.org wrote:
I've tried to create a patch, but didn't see how I'd convert the result
from get_typedefault() (A Node*, presumeably the parsetree corresponding
to the default expression?) into a plan that I could store
On Fri, Nov 20, 2009 at 12:51 PM, Florian G. Pflug f...@phlo.org wrote:
Robert Haas wrote:
On Thu, Nov 19, 2009 at 9:06 PM, Florian G. Pflug f...@phlo.org wrote:
I've tried to create a patch, but didn't see how I'd convert the result
from get_typedefault() (A Node*, presumeably the parsetree
Florian G. Pflug f...@phlo.org writes:
It seems that pl/pgsql ignores the DEFAULT value of domains for local
variables.
The plpgsql documentation seems entirely clear on this:
The DEFAULT clause, if given, specifies the initial value assigned to
the variable when the block is
Tom Lane wrote:
Florian G. Pflug f...@phlo.org writes:
It seems that pl/pgsql ignores the DEFAULT value of domains for
local variables.
The plpgsql documentation seems entirely clear on this:
The DEFAULT clause, if given, specifies the initial value assigned to
the variable when the block
Would a patch that changes that have any chance of being accepted? Or is
the gain (not having to repeat the DEFAULT clause, and being able to
maintain it at one place instead of many) considered too small compared
to the risk of breaking existing code?
I don't think there's a lot of risk of
Hi
It seems that pl/pgsql ignores the DEFAULT value of domains for local
variables. With the following definitions in place
create domain myint as int default 0;
create or replace function myint() returns myint as $body$
declare
v_result myint;
begin
return v_result;
end;
$body$ language
13 matches
Mail list logo
