On 4/28/15 1:31 PM, Andrew Dunstan wrote:
On 04/28/2015 01:44 PM, Jim Nasby wrote:
On 4/27/15 10:06 PM, Andrew Dunstan wrote:
My point remains that we really need methods of a) getting the field
names from generic records and b) using text values to access fields of
generic records, both as lv
On 04/28/2015 01:44 PM, Jim Nasby wrote:
On 4/27/15 10:06 PM, Andrew Dunstan wrote:
My point remains that we really need methods of a) getting the field
names from generic records and b) using text values to access fields of
generic records, both as lvalues and rvalues. Without those this featu
On Tue, Apr 28, 2015 at 12:44 PM, Jim Nasby wrote:
> On 4/27/15 10:06 PM, Andrew Dunstan wrote:
>>
>> My point remains that we really need methods of a) getting the field
>> names from generic records and b) using text values to access fields of
>> generic records, both as lvalues and rvalues. Wit
On 4/27/15 10:06 PM, Andrew Dunstan wrote:
My point remains that we really need methods of a) getting the field
names from generic records and b) using text values to access fields of
generic records, both as lvalues and rvalues. Without those this feature
will be of comparatively little value, I
On 04/27/2015 10:35 PM, Jim Nasby wrote:
On 4/25/15 4:50 PM, Tom Lane wrote:
Well, we already support local variables of type RECORD in plpgsql, so
it's not immediately clear to me that function arguments would be much
worse. There are a lot of deficiencies with the RECORD-local-variable
imple
On 4/25/15 4:50 PM, Tom Lane wrote:
Well, we already support local variables of type RECORD in plpgsql, so
it's not immediately clear to me that function arguments would be much
worse. There are a lot of deficiencies with the RECORD-local-variable
implementation: if you try to change the actual
Robert Haas writes:
> On Wed, Apr 22, 2015 at 6:12 PM, Jim Nasby wrote:
>> As for allowing SQL and plpgsql functions to accept a record, I think our
>> JSON functionality just provided plenty of reason we should allow accepting
>> them, even if you can't do much with it: you *can* hand it to row_
On 4/23/15 8:33 AM, Pavel Stehule wrote:
I agree that that would be useful. I think the problem with an
expression like rowvar.something is that PL/pgsql cannot infer the
type of the result, and nothing else works without that. I doubt that
it's practical to lift that restrictio
2015-04-23 15:19 GMT+02:00 Robert Haas :
> On Wed, Apr 22, 2015 at 6:12 PM, Jim Nasby
> wrote:
> > On 4/22/15 2:12 PM, Merlin Moncure wrote:
> >> That being said, I think json types with their associated API, given
> >> that they are core types, will ultimately handle these types of
> >> problems
On Wed, Apr 22, 2015 at 6:12 PM, Jim Nasby wrote:
> On 4/22/15 2:12 PM, Merlin Moncure wrote:
>> That being said, I think json types with their associated API, given
>> that they are core types, will ultimately handle these types of
>> problems. That way, at least, we can avoid adding syntax and
On 4/22/15 2:12 PM, Merlin Moncure wrote:
That being said, I think json types with their associated API, given
that they are core types, will ultimately handle these types of
problems. That way, at least, we can avoid adding syntax and
functionality that will basically do the same thing. This r
On Wed, Apr 22, 2015 at 11:20 AM, Andrew Dunstan wrote:
>
> On 04/22/2015 11:29 AM, Jim Nasby wrote:
>>
>> On 4/20/15 2:04 PM, David G. Johnston wrote:
>>>
>>>
>>> SELECT (src.v).* FROM ( VALUES (ROW(1,2,3)) ) src (v);
>>> ERROR: record type has not been registered
>>>
>>> While it may not be nece
On 04/22/2015 11:29 AM, Jim Nasby wrote:
On 4/20/15 2:04 PM, David G. Johnston wrote:
SELECT (src.v).* FROM ( VALUES (ROW(1,2,3)) ) src (v);
ERROR: record type has not been registered
While it may not be necessary to solve both problems I suspect they have
the same underlying root cause - s
On 4/20/15 2:04 PM, David G. Johnston wrote:
SELECT (src.v).* FROM ( VALUES (ROW(1,2,3)) ) src (v);
ERROR: record type has not been registered
While it may not be necessary to solve both problems I suspect they have
the same underlying root cause - specifically the separation of concerns
betw
On Sun, Apr 19, 2015 at 3:02 PM, Jim Nasby wrote:
> Is there a fundamental reason SQL/plpgsql functions won't accept record as
> an input type? If not, can someone point me at a patch that might show how
> much work would be involved in adding support?
>
> My particular use case is a generic func
Is there a fundamental reason SQL/plpgsql functions won't accept record
as an input type? If not, can someone point me at a patch that might
show how much work would be involved in adding support?
My particular use case is a generic function that will count how many
fields in a record are NULL
16 matches
Mail list logo
