On Oct 28, 2010, at 9:31 AM, Andrew Dunstan wrote:
> Of course it's possible, but it's a different feature. As for "just as easy",
> no, it's much more work. I agree it should be done, though.
I bet we could raise some money to fund it's development. How much work are we
talking about here?
Be
On Oct 27, 2010, at 9:08 PM, Andrew Dunstan wrote:
> Well, it turns out that the hashref required exactly one more line to
> achieve. We already have all the infrastructure on the composite handling
> code, and all it requires it to enable it for the RECORDOID case.
I don't suppose that it woul
On 10/28/2010 12:23 PM, David E. Wheeler wrote:
On Oct 27, 2010, at 9:08 PM, Andrew Dunstan wrote:
Well, it turns out that the hashref required exactly one more line to achieve.
We already have all the infrastructure on the composite handling code, and all
it requires it to enable it for th
On 10/27/2010 11:38 PM, Tom Lane wrote:
Andrew Dunstan writes:
But I think we can do better than this. We should really pass an hashref
with the record's column names as keys rather than just calling
record_out. I'll work on that.
Definitely. If you aren't providing that info then it's hard
Andrew Dunstan writes:
> But I think we can do better than this. We should really pass an hashref
> with the record's column names as keys rather than just calling
> record_out. I'll work on that.
Definitely. If you aren't providing that info then it's hard to write
a generic function, which i
On 10/25/2010 09:32 PM, Andrew Dunstan wrote:
On 10/25/2010 07:12 PM, Tom Lane wrote:
However, that objection doesn't hold for plperl or pltcl (and likely
not plpython, though I don't know that language enough to be sure).
So it would be a reasonable feature request to teach those PLs to
acce
On 10/25/2010 09:32 PM, Andrew Dunstan wrote:
On 10/25/2010 07:12 PM, Tom Lane wrote:
However, that objection doesn't hold for plperl or pltcl (and likely
not plpython, though I don't know that language enough to be sure).
So it would be a reasonable feature request to teach those PLs to
acce
Hi Merlin, I completely forgot about hstore! I'll give it a go. Thanks!
From: Merlin Moncure
To: Greg
Cc: Pavel Stehule ; pgsql-hackers@postgresql.org
Sent: Mon, 25 October, 2010 23:52:55
Subject: Re: [HACKERS] Composite Types and Function Parameters
O
On 10/25/2010 07:12 PM, Tom Lane wrote:
However, that objection doesn't hold for plperl or pltcl (and likely
not plpython, though I don't know that language enough to be sure).
So it would be a reasonable feature request to teach those PLs to
accept "record" parameters. I think the fact that t
On Oct 25, 2010, at 4:12 PM, Tom Lane wrote:
> However, that objection doesn't hold for plperl or pltcl (and likely
> not plpython, though I don't know that language enough to be sure).
> So it would be a reasonable feature request to teach those PLs to
> accept "record" parameters. I think the f
Merlin Moncure writes:
> probably hstore would be more appropriate for something like that.
An array is certainly completely the wrong thing if you don't intend
all the items to be the same datatype...
> You can also declare functions taking composite arrays, anyarray,
> variadic array, and vari
On Mon, Oct 25, 2010 at 6:38 PM, Greg wrote:
>
> Hi Pavel, thanks! Yeah, thats what I though. I have to have a custom type or
> a very ugly looking solution for passing the params then.
>
> To Postgre dev. team: If anyone who involved in Postgre development reading
> this, just a feature suggest
.
Thanks!
From: Pavel Stehule
To: Greg
Cc: pgsql-hackers@postgresql.org
Sent: Mon, 25 October, 2010 17:46:47
Subject: Re: [HACKERS] Composite Types and Function Parameters
Hello
I am thinking, so it isn't possible. There are a general datatype anyelement,
b
Hello
I am thinking, so it isn't possible. There are a general datatype
anyelement, but it cannot accept a second general type record.
CREATE TYPE p AS (a text, b int, c bool);
CREATE OR REPLACE FUNCTION fp(p)
RETURNS int AS $$
BEGIN RAISE NOTICE 'a = %', $1.a; RETURN $1.b;
END;
$$ LANGUAGE plpg
Hi guys, got across an interesting problem of passing params to a function in
postgre: is it possible to pass a composite parameter to a function without
declaring a type first?
For example:
// declare a function
create function TEST ( object??? )
object???.paramName // using par
15 matches
Mail list logo
