Excerpts from Merlin Moncure's message of mar nov 09 16:41:32 -0300 2010:
> The only exception I see is in trigger functions. If the trigger
> function plan is specific to the firing trigger, new and old are
> defined at plan time, so something like:
>
> new{TG_FIELDNAMES[1]} = 5; -- is ok (at
On Tue, Nov 9, 2010 at 12:34 PM, Tom Lane wrote:
> "David E. Wheeler" writes:
>> You realize you can pretty much do all this with hstore, right?
>
> Yeah. Anything that involves smashing all the fields to text is not
> really an advance over (a) hstore or (b) using plperl or one of the
> other w
>>
>> What are you going to do with the type once you have it?
>>
>
> for example, you can use it for formatting, for explicit cast, for
> different serialization type - like JSON - without knowledge of type,
> you can't to build correct JSON value. So you can write a application
> with knowledge o
2010/11/9 David E. Wheeler :
> On Nov 9, 2010, at 9:35 AM, Pavel Stehule wrote:
>
>> hstore has similar functionality, but missing a some details and add
>> lot of other functionality - it doesn't identify type of field.
>> Personally - it is nothing what I like - but can be better than
>> nothing.
2010/11/9 David E. Wheeler :
> On Nov 9, 2010, at 9:34 AM, Tom Lane wrote:
>
>> I think there's a fairly fundamental contradiction involved here.
>> One of the basic design attributes of plpgsql is that it's strongly
>> typed. Sometimes that's a blessing, and sometimes it's not, but
>> it's a fact
2010/11/9 David E. Wheeler :
> On Nov 9, 2010, at 9:35 AM, Pavel Stehule wrote:
>
>>> You realize you can pretty much do all this with hstore, right?
>>
>> hstore has similar functionality, but missing a some details and add
>> lot of other functionality - it doesn't identify type of field.
>> Pers
On Nov 9, 2010, at 9:35 AM, Pavel Stehule wrote:
> hstore has similar functionality, but missing a some details and add
> lot of other functionality - it doesn't identify type of field.
> Personally - it is nothing what I like - but can be better than
> nothing.
What are you going to do with the
On Nov 9, 2010, at 9:34 AM, Tom Lane wrote:
> I think there's a fairly fundamental contradiction involved here.
> One of the basic design attributes of plpgsql is that it's strongly
> typed. Sometimes that's a blessing, and sometimes it's not, but
> it's a fact. There really isn't a good way to
2010/11/9 Tom Lane :
> "David E. Wheeler" writes:
>> You realize you can pretty much do all this with hstore, right?
>
> Yeah. Anything that involves smashing all the fields to text is not
> really an advance over (a) hstore or (b) using plperl or one of the
> other weakly-typed PLs.
>
> I think
On Nov 9, 2010, at 9:35 AM, Pavel Stehule wrote:
>> You realize you can pretty much do all this with hstore, right?
>
> hstore has similar functionality, but missing a some details and add
> lot of other functionality - it doesn't identify type of field.
> Personally - it is nothing what I like -
2010/11/9 David E. Wheeler :
> On Nov 9, 2010, at 1:38 AM, Dmitriy Igrishin wrote:
>
>> * text[] = record_to_array(record)
>> * table(id, key, datatype, value) = record_to_table(record)
>> * text = record_get_field(record, text)
>> * record = record_set_field(record, text, anyelement)
>>
>> ??
>> I
"David E. Wheeler" writes:
> You realize you can pretty much do all this with hstore, right?
Yeah. Anything that involves smashing all the fields to text is not
really an advance over (a) hstore or (b) using plperl or one of the
other weakly-typed PLs.
I think there's a fairly fundamental contr
On Nov 9, 2010, at 9:18 AM, Dmitriy Igrishin wrote:
> Yep, but hstore is an additional module. Although, its not a problem.
Yeah, but JSON will be in core, and with luck, before long, it will have the
same (or similar) capabilities.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-
Hey David,
2010/11/9 David E. Wheeler
> On Nov 9, 2010, at 1:38 AM, Dmitriy Igrishin wrote:
>
> > * text[] = record_to_array(record)
> > * table(id, key, datatype, value) = record_to_table(record)
> > * text = record_get_field(record, text)
> > * record = record_set_field(record, text, anyelemen
On Nov 9, 2010, at 1:38 AM, Dmitriy Igrishin wrote:
> * text[] = record_to_array(record)
> * table(id, key, datatype, value) = record_to_table(record)
> * text = record_get_field(record, text)
> * record = record_set_field(record, text, anyelement)
>
> ??
> I personally like it. But I propose to
Hey Pavel,
2010/11/9 Pavel Stehule
> > a) transformation to common type
> >
> > + simple - it is one day job - function record_to_array,
> > array_to_record, and fieldnames_to_array
> > - lost of type info, hidden problems with IO cast - int a := 10.0/2.0
> > is a problem
> >
> > using a plperl
> a) transformation to common type
>
> + simple - it is one day job - function record_to_array,
> array_to_record, and fieldnames_to_array
> - lost of type info, hidden problems with IO cast - int a := 10.0/2.0
> is a problem
>
> using a plperl, pltcl is same like @a
>
I thinking about some simpl
>>
>> What is solution in your design?
>
> nothing specific. My main interest is in the plan management portion
> (only because of side interest in search_path which is complete mess
> at present). if plpgsql_compile knows that it is trigger function and
> which table fired the trigger, you can
On Mon, Nov 8, 2010 at 3:21 PM, Pavel Stehule wrote:
> 2010/11/8 Merlin Moncure :
>> On Mon, Nov 8, 2010 at 3:00 PM, Pavel Stehule
>> wrote:
Most cases of this feature are for dealing with new/old from trigger
function right? Why not build a complete new plan for each specific
tr
2010/11/8 Merlin Moncure :
> On Mon, Nov 8, 2010 at 3:00 PM, Pavel Stehule wrote:
>>> Most cases of this feature are for dealing with new/old from trigger
>>> function right? Why not build a complete new plan for each specific
>>> trigger that invokes the function, along with some magic values li
Merlin,
Sorry, I don't clearly understand what the problem here, but I just want to
avoid
conversion from record to hstore with suggested API. I am currently happy
with
hstore API to work with record. From the user's point of view :-).
2010/11/8 Merlin Moncure
> On Mon, Nov 8, 2010 at 3:02 PM,
Hello
2010/11/8 Dmitriy Igrishin :
> Hey Pavel, Tom, Merlin,
>
> As a user, I would like to work with records by using simple API:
>
> -- Returns a number of key/values pairs of record.
> nKeys_ integer := nRecordKeys(NEW);
>
> -- Returns an i-th key.
> key_i text := recordKey(NEW, i);
>
On Mon, Nov 8, 2010 at 3:00 PM, Pavel Stehule wrote:
>> Most cases of this feature are for dealing with new/old from trigger
>> function right? Why not build a complete new plan for each specific
>> trigger that invokes the function, along with some magic values like
>> (TG_FIELDNAMES -> text[])
On Mon, Nov 8, 2010 at 3:02 PM, Dmitriy Igrishin wrote:
> Hey Pavel, Tom, Merlin,
>
> As a user, I would like to work with records by using simple API:
>
> -- Returns a number of key/values pairs of record.
> nKeys_ integer := nRecordKeys(NEW);
>
> -- Returns an i-th key.
> key_i text := r
Hey Pavel, Tom, Merlin,
As a user, I would like to work with records by using simple API:
-- Returns a number of key/values pairs of record.
nKeys_ integer := nRecordKeys(NEW);
-- Returns an i-th key.
key_i text := recordKey(NEW, i);
-- Returns an i-th value.
value1_ text := recordV
2010/11/8 Merlin Moncure :
> On Mon, Nov 8, 2010 at 2:29 PM, Pavel Stehule wrote:
>> 2010/11/8 Tom Lane :
>>> Pavel Stehule writes:
FOR varname OVER [row | rec variable]
LOOP
{{body}}
END LOOP
>>>
this syntax isn't final. The real type of control variable is
speci
On Mon, Nov 8, 2010 at 2:29 PM, Pavel Stehule wrote:
> 2010/11/8 Tom Lane :
>> Pavel Stehule writes:
>>> FOR varname OVER [row | rec variable]
>>> LOOP
>>> {{body}}
>>> END LOOP
>>
>>> this syntax isn't final. The real type of control variable is
>>> specified in runtime and can be changed bet
2010/11/8 Tom Lane :
> Pavel Stehule writes:
>> FOR varname OVER [row | rec variable]
>> LOOP
>> {{body}}
>> END LOOP
>
>> this syntax isn't final. The real type of control variable is
>> specified in runtime and can be changed between iterations.
>
> If you don't know the type or even the name
Pavel Stehule writes:
> FOR varname OVER [row | rec variable]
> LOOP
>{{body}}
> END LOOP
> this syntax isn't final. The real type of control variable is
> specified in runtime and can be changed between iterations.
If you don't know the type or even the name of the field that varname
curren
29 matches
Mail list logo
