2009/12/3 Alvaro Herrera :
> Pavel Stehule escribió:
>> 2009/11/18 Peter Eisentraut :
>> > On ons, 2009-11-18 at 11:46 +0100, Pavel Stehule wrote:
>> >> I am not sure if SQL standard is good inspiration in this case.
>> >
>> > I'm not sure either, but I think it's premature to make a conclusion
>>
Pavel Stehule escribió:
> 2009/11/18 Peter Eisentraut :
> > On ons, 2009-11-18 at 11:46 +0100, Pavel Stehule wrote:
> >> I am not sure if SQL standard is good inspiration in this case.
> >
> > I'm not sure either, but I think it's premature to make a conclusion
> > about that without having checked
Tom Lane wrote:
> there is a constituency that cares --- mainly people who use
> client-side code that tends to fall over if it doesn't see a
> suitable maxlength attached to query result columns.
I suspect it will primarily be software which is dealing with large
enough result sets that readi
2009/11/18 Peter Eisentraut :
> On ons, 2009-11-18 at 11:46 +0100, Pavel Stehule wrote:
>> I am not sure if SQL standard is good inspiration in this case.
>
> I'm not sure either, but I think it's premature to make a conclusion
> about that without having checked at all.
ok, I recheck SQL/PSM part
On ons, 2009-11-18 at 11:46 +0100, Pavel Stehule wrote:
> I am not sure if SQL standard is good inspiration in this case.
I'm not sure either, but I think it's premature to make a conclusion
about that without having checked at all.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
2009/11/18 Peter Eisentraut :
> On tis, 2009-11-17 at 17:09 -0500, Tom Lane wrote:
>> I can see the following definitional issues:
>
> Should we be able to find the answers to those, or at least a basis of
> discussion about those, in the SQL standard? Has anyone checked?
>
I am not sure if SQL s
On tis, 2009-11-17 at 17:09 -0500, Tom Lane wrote:
> I can see the following definitional issues:
Should we be able to find the answers to those, or at least a basis of
discussion about those, in the SQL standard? Has anyone checked?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postg
>
> 4. What about functions whose output typmod should depend on the input
> typmod(s)? I mentioned earlier the example that concatenation of
> varchar(M) and varchar(N) should produce varchar(M+N). We could possibly
> punt on this for the time being; supporting only fixed output typmods for
> n
>
> So I guess really can't get worked up about the idea of propagating
> this information through the type system. Even suppose we eventually
> take the steps you suggesting and make it so that varchar(30) ||
> varchar(40) yields varchar(70). What good is that?
I see main sense in enhancing war
On Tue, Nov 17, 2009 at 7:46 PM, Tom Lane wrote:
> Robert Haas writes:
>> So I guess really can't get worked up about the idea of propagating
>> this information through the type system. Even suppose we eventually
>> take the steps you suggesting and make it so that varchar(30) ||
>> varchar(40)
Robert Haas writes:
> So I guess really can't get worked up about the idea of propagating
> this information through the type system. Even suppose we eventually
> take the steps you suggesting and make it so that varchar(30) ||
> varchar(40) yields varchar(70). What good is that? Why would anyo
On Tue, Nov 17, 2009 at 6:01 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> Apart from all these it's not clear to me what the major benefits of
>> doing this would be. I'd like an explanation of that to start with.
>
> Well, aside from the issue about making "anyelement" more powerful
> (which
Andrew Dunstan writes:
> Apart from all these it's not clear to me what the major benefits of
> doing this would be. I'd like an explanation of that to start with.
Well, aside from the issue about making "anyelement" more powerful
(which could be done in other ways), I can think of:
If we don't
Tom Lane wrote:
Pavel submitted a patch to add typmods to function declarations, but there
was no prior design discussion and it desperately needs some. Let me try
to summarize the issues that seem to need agreement.
[excellent summary of problem areas snipped]
Unless we have consensus
Pavel submitted a patch to add typmods to function declarations, but there
was no prior design discussion and it desperately needs some. Let me try
to summarize the issues that seem to need agreement.
The proposed patch allows optional typmods to be attached to the declared
argument and result ty
15 matches
Mail list logo
