2010/5/31 Bruce Momjian :
> Pavel Stehule wrote:
>> 2010/4/15 Tom Lane :
>> > Pavel Stehule writes:
>> >> I think, so RETURNS TABLE can be modified for returning typmode
>> >> without significant problems - this function is called in table
>> >> context and I don't see any problematic use case.
>>
Pavel Stehule wrote:
> 2010/4/15 Tom Lane :
> > Pavel Stehule writes:
> >> I think, so RETURNS TABLE can be modified for returning typmode
> >> without significant problems - this function is called in table
> >> context and I don't see any problematic use case.
> >
> > RETURNS TABLE is just a sho
2010/4/15 Tom Lane :
> Pavel Stehule writes:
>> I think, so RETURNS TABLE can be modified for returning typmode
>> without significant problems - this function is called in table
>> context and I don't see any problematic use case.
>
> RETURNS TABLE is just a shorthand for some OUT parameters. I
Pavel Stehule writes:
> I think, so RETURNS TABLE can be modified for returning typmode
> without significant problems - this function is called in table
> context and I don't see any problematic use case.
RETURNS TABLE is just a shorthand for some OUT parameters. I don't
believe it's either eas
Hello, Tom.
You wrote:
TL> Pavel Golub writes:
>> Example:
>> CREATE OR REPLACE FUNCTION test_char_function()
>> RETURNS TABLE(id int, salesourcecode character) AS
>> $BODY$
>> VALUES (1, 'one'), (2, 'two'), (3, 'three');
>> $BODY$
>> LANGUAGE 'sql'
>> pqfmod function from libpq library fo
2010/4/15 Tom Lane :
> "Kevin J Bluck" writes:
>> But if RETURN TABLE doesn't respect typemods, perhaps it shouldn't be
>> legal to specify them in that clause?
>
> Yeah, possibly. CREATE FUNCTION has historically accepted (and then
> discarded) typmod information for all function parameter and r
On 15/04/2010 10:25 AM, Tom Lane wrote:
Craig Ringer writes:
So - I do think there's a bug here, if _tables_ can be created with
character(1) fields containing three- or four-character strings.
[ shrug... ] If you can demonstrate such a behavior, I'd agree it's a
bug, but the examples at han
Craig Ringer writes:
> So - I do think there's a bug here, if _tables_ can be created with
> character(1) fields containing three- or four-character strings.
[ shrug... ] If you can demonstrate such a behavior, I'd agree it's a
bug, but the examples at hand have nothing to do with what gets sto
On 15/04/2010 8:05 AM, Tom Lane wrote:
"Kevin J Bluck" writes:
But if RETURN TABLE doesn't respect typemods, perhaps it shouldn't be
legal to specify them in that clause?
Yeah, possibly. CREATE FUNCTION has historically accepted (and then
discarded) typmod information for all function parame
"Kevin J Bluck" writes:
> But if RETURN TABLE doesn't respect typemods, perhaps it shouldn't be
> legal to specify them in that clause?
Yeah, possibly. CREATE FUNCTION has historically accepted (and then
discarded) typmod information for all function parameter and result
types; RETURNS TABLE doe
>> PostgreSQL functions ignore typmod for parameters...
> ...not something that can be changed without a great
> deal of work --- and application breakage...
Thanks to all for the clarifications. I can make it return what I wanted with
qualified character types by returning a SETOF RECORD types,
Pavel Stehule writes:
> RETURNS TABLE (x int, y int) is equal to CREATE FUNCTION foo(.. OUT x
> int, OUT y int) RETURNS SETOF RECORD. But PostgreSQL functions ignore
> typmod for parameters - so it is not bug, it is feature :(
Yeah. Or at least, this is not something that can be changed without
Pavel Golub writes:
> Example:
> CREATE OR REPLACE FUNCTION test_char_function()
> RETURNS TABLE(id int, salesourcecode character) AS
> $BODY$
> VALUES (1, 'one'), (2, 'two'), (3, 'three');
> $BODY$
> LANGUAGE 'sql'
> pqfmod function from libpq library for salesourcecode column returns
> 0,
2010/4/14 Kevin J Bluck :
>> I'd certainly call this a bug, if not a couple of different bugs.
>
> There seems to be more. I see a problem not just with unqualified char not
> being treated equivalent to char(1). I also see a general problem with
> RETURNS TABLE disregarding any explicit lengths
> I'd certainly call this a bug, if not a couple of different bugs.
There seems to be more. I see a problem not just with unqualified char not
being treated equivalent to char(1). I also see a general problem with RETURNS
TABLE disregarding any explicit lengths declared for any character type. F
Pavel Golub wrote:
> Hello, Pgsql-bugs.
>
> PostgreSQL version: 8.4.x
> Operating system: All
>
> If RETURNS TABLE clause of CREATE FUNCTION contain column of character type
> (withou
> length specifier) it should be treated as character(1) according to
> manual, but it look like text.
> (http
Hello, Pgsql-bugs.
PostgreSQL version: 8.4.x
Operating system: All
If RETURNS TABLE clause of CREATE FUNCTION contain column of character type
(withou
length specifier) it should be treated as character(1) according to
manual, but it look like text.
(http://www.postgresql.org/docs/8.4/static/d
17 matches
Mail list logo
