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
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 would
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?
Best,
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
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
Andrew Dunstan and...@dunslane.net 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
On 10/27/2010 11:38 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net 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
: Re: [HACKERS] Composite Types and Function Parameters
On Mon, Oct 25, 2010 at 6:38 PM, Greg grigo...@yahoo.co.uk 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
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
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
.
Thanks!
From: Pavel Stehule pavel.steh...@gmail.com
To: Greg grigo...@yahoo.co.uk
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
On Mon, Oct 25, 2010 at 6:38 PM, Greg grigo...@yahoo.co.uk 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
Merlin Moncure mmonc...@gmail.com 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
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 fact
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
15 matches
Mail list logo
