On 17.03.10 4:08 , Merlin Moncure wrote:
On Tue, Mar 16, 2010 at 5:53 PM, Florian
Pflug wrote:
which returns the field named from the record. The
expected field type is specified by providing a default value
in of the expected type. Since that argument's type is
ANYELEMENT, just like the retu
On Tue, Mar 16, 2010 at 5:53 PM, Florian Pflug wrote:
> which returns the field named from the record. The expected
> field type is specified by providing a default value in of the
> expected type. Since that argument's type is ANYELEMENT, just like the
> return type, the type system copes perfe
On 13.03.10 18:38 , Tom Lane wrote:
I wrote:
... Maybe it would work to devise a notation that allows fetching
or storing a field that has a runtime-determined name, but
prespecifies the field type. Actually only the "fetch" end of it is
an issue, since when storing the field datatype can be inf
On Mon, Mar 15, 2010 at 12:19 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> On Mon, Mar 15, 2010 at 11:37 AM, Tom Lane wrote:
>>> If we make the implementation be such that "(rec->field)::foo" forces
>>> a runtime cast to foo (rather than throwing an error if it's not type
>>> foo already)
>
>
Merlin Moncure writes:
> On Mon, Mar 15, 2010 at 11:37 AM, Tom Lane wrote:
>> If we make the implementation be such that "(rec->field)::foo" forces
>> a runtime cast to foo (rather than throwing an error if it's not type
>> foo already)
> yeah...explicit cast should always do 'best effort'
Prob
On Mon, Mar 15, 2010 at 11:37 AM, Tom Lane wrote:
> If we make the implementation be such that "(rec->field)::foo" forces
a runtime cast to foo (rather than throwing an error if it's not type
foo already)
yeah...explicit cast should always do 'best effort'
> The cost of looking up the ever-chang
Merlin Moncure writes:
> On Mon, Mar 15, 2010 at 10:02 AM, Andrew Dunstan wrote:
>> Not quite, but close. We also need a nice way of querying for field names
>> (at least) at run time. I've seen that requested several times.
> does the parse/plan objection still hold?
Yeah. Providing the field
On Mon, Mar 15, 2010 at 10:02 AM, Andrew Dunstan wrote:
> Not quite, but close. We also need a nice way of querying for field names
> (at least) at run time. I've seen that requested several times.
ok. just making sure we were on the same page. wasn't there a
technical objection to querying the f
Merlin Moncure wrote:
record->fieldname takes a string (possibly a variable)?
If it doesn't we have a communication problem. :-)
If so, his would nail the problem.
Not quite, but close. We also need a nice way of querying for field
names (at least) at run time. I've seen that requested
On Sat, Mar 13, 2010 at 1:38 PM, Tom Lane wrote:
> I wonder if it could work to treat the result of a "record->fieldname"
> operator as being of UNKNOWN type initially, and resolve its actual
> type in the parser in the same way we do for undecorated literals
> and parameters, to wit
> * yo
I wrote:
> ... Maybe it would
> work to devise a notation that allows fetching or storing a field that
> has a runtime-determined name, but prespecifies the field type.
> Actually only the "fetch" end of it is an issue, since when storing the
> field datatype can be inferred from the expression you
Tom Lane wrote:
ISTM that in most cases where this is a serious issue, the trigger
functions are doing the *same* thing to different tables. Not just
textually the same, but datatype-wise the same. So I'm not sure I
believe that we need to be able to "switch out types". Maybe it would
work
On Sat, Mar 13, 2010 at 12:18:32PM -0500, Tom Lane wrote:
> Merlin Moncure writes:
> > ... It just doesn't seem right that you should have to write N
> > trigger functions over N tables to a highly related operations.
> > pl/perl is a huge dependency to bring in just to able to do things
> > this.
Merlin Moncure writes:
> ... It just doesn't seem right that you should have to
> write N trigger functions over N tables to a highly related
> operations. pl/perl is a huge dependency to bring in just to able to
> do things this. I understand hacking things through the text route is
> possibly
2010/3/13 Tom Lane :
> Merlin Moncure writes:
>> On Sat, Mar 13, 2010 at 11:40 AM, Tom Lane wrote:
>>> (This will also be my main objection to letting hstore into core.
>>> It has not solved the problem of handling real datatypes.)
>
>> Is this problem solvable then?
>
> I don't know, but hstore
Merlin Moncure writes:
> On Sat, Mar 13, 2010 at 11:40 AM, Tom Lane wrote:
>> (This will also be my main objection to letting hstore into core.
>> It has not solved the problem of handling real datatypes.)
> Is this problem solvable then?
I don't know, but hstore hasn't even tried. We should b
2010/3/13 Tom Lane :
> Andrew Dunstan writes:
>> I think we need some operator on records+strings for this functionality.
>
> I don't see how you're going to do that without utterly compromising the
> type system.
>
> It's not so horrid to do this type of thing in plperl, pltcl etc because
> you'v
On Sat, Mar 13, 2010 at 11:40 AM, Tom Lane wrote:
> (This will also be my main objection to letting hstore into core.
> It has not solved the problem of handling real datatypes.)
Is this problem solvable then? Some variant of this question comes up
almost weekly. It just doesn't seem right that
Andrew Dunstan writes:
> I think we need some operator on records+strings for this functionality.
I don't see how you're going to do that without utterly compromising the
type system.
It's not so horrid to do this type of thing in plperl, pltcl etc because
you've already bought into an "everyth
Pavel Stehule wrote:
I see some disadvantages
a) non intuitive name - hstore is very specific name
b) effectivity (mainly inside trigger body) - plpgsql specific
construct can be 10x faster.
I would to see hash tables in core too, but I don't think so it is
good solution for record updating.
On Fri, Mar 12, 2010 at 4:24 PM, Boszormenyi Zoltan wrote:
> Merlin Moncure írta:
>> On Fri, Mar 12, 2010 at 3:01 PM, Boszormenyi Zoltan wrote:
>>
>>> What's wrong with "UPDATE foo SET (foo) = (NEW);" ?
>>>
>>>
>>
>> amen brother! :-)
>>
>> I say though, since you can do:
>> SELECT foo FROM foo;
Merlin Moncure írta:
> On Fri, Mar 12, 2010 at 3:01 PM, Boszormenyi Zoltan wrote:
>
>> What's wrong with "UPDATE foo SET (foo) = (NEW);" ?
>>
>>
>
> amen brother! :-)
>
> I say though, since you can do:
> SELECT foo FROM foo;
> why not
> UPDATE foo SET foo = new;?
>
I just tried this:
On Fri, Mar 12, 2010 at 3:01 PM, Boszormenyi Zoltan wrote:
>
> What's wrong with "UPDATE foo SET (foo) = (NEW);" ?
>
amen brother! :-)
I say though, since you can do:
SELECT foo FROM foo;
why not
UPDATE foo SET foo = new;?
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq
strk írta:
> On Fri, Mar 12, 2010 at 10:47:45AM -0800, David Fetter wrote:
>
>> On Fri, Mar 12, 2010 at 07:35:41PM +0100, Pavel Stehule wrote:
>>
>>> 2010/3/12 David Fetter :
>>>
This is, by the way, an excellent argument for including hstore in
core in 9.1. :)
2010/3/12 strk :
> On Fri, Mar 12, 2010 at 10:47:45AM -0800, David Fetter wrote:
>> On Fri, Mar 12, 2010 at 07:35:41PM +0100, Pavel Stehule wrote:
>> > 2010/3/12 David Fetter :
>> > >
>> > > This is, by the way, an excellent argument for including hstore in
>> > > core in 9.1. :)
>> >
>> > I like i
On Fri, Mar 12, 2010 at 10:47:45AM -0800, David Fetter wrote:
> On Fri, Mar 12, 2010 at 07:35:41PM +0100, Pavel Stehule wrote:
> > 2010/3/12 David Fetter :
> > >
> > > This is, by the way, an excellent argument for including hstore in
> > > core in 9.1. :)
> >
> > I like it - but it looking little
On Fri, Mar 12, 2010 at 07:35:41PM +0100, Pavel Stehule wrote:
> 2010/3/12 David Fetter :
> >
> > This is, by the way, an excellent argument for including hstore in
> > core in 9.1. :)
>
> I like it - but it looking little bit strange - I thinking we need
> only one function (maybe with some speci
2010/3/12 David Fetter :
> On Wed, Mar 10, 2010 at 07:50:16AM -0500, Andrew Dunstan wrote:
>> hubert depesz lubaczewski wrote:
>> >On Tue, Mar 09, 2010 at 06:59:31PM +0100, Pavel Stehule wrote:
>> >>2010/3/9 strk :
>> >>>How can a pl/pgsql trigger change the
>> >>>values of dynamic fields in NEW re
On Wed, Mar 10, 2010 at 07:50:16AM -0500, Andrew Dunstan wrote:
> hubert depesz lubaczewski wrote:
> >On Tue, Mar 09, 2010 at 06:59:31PM +0100, Pavel Stehule wrote:
> >>2010/3/9 strk :
> >>>How can a pl/pgsql trigger change the
> >>>values of dynamic fields in NEW record ?
> >>>
> >>>By "dynamic" I
On Thu, Mar 11, 2010 at 11:24 PM, Alvaro Herrera
wrote:
> Merlin Moncure escribió:
>
>
>> (small aside: the other biggie would be able to push a composite type
>> in to an update statement...something like 'update foo set foo =
>> new'). This is really great...some variant of this question is
>>
Merlin Moncure escribió:
> (small aside: the other biggie would be able to push a composite type
> in to an update statement...something like 'update foo set foo =
> new'). This is really great...some variant of this question is
> continually asked it seems.
Can't you already do that with EXECU
On Wed, Mar 10, 2010 at 7:50 AM, Andrew Dunstan wrote:
>>> 2010/3/9 strk :
How can a pl/pgsql trigger change the
values of dynamic fields in NEW record ?
By "dynamic" I mean that the field name
is a variable in the trigger context.
I've been told it's easy to do
On Thu, Mar 11, 2010 at 03:27:23PM +0100, strk wrote:
> On Wed, Mar 10, 2010 at 07:50:16AM -0500, Andrew Dunstan wrote:
>
> > Using an hstore in 9.0 it's not too bad,
>
> Does it still have a limit of 65535 bytes per field ?
No. :)
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 4
On Wed, Mar 10, 2010 at 07:50:16AM -0500, Andrew Dunstan wrote:
> Using an hstore in 9.0 it's not too bad,
Does it still have a limit of 65535 bytes per field ?
--strk;
() Free GIS & Flash consultant/developer
/\ http://strk.keybit.net/services.html
--
Sent via pgsql-hackers mailing l
> How can a pl/pgsql trigger change the
> values of dynamic fields in NEW record ?
>
> By "dynamic" I mean that the field name
> is a variable in the trigger context.
It's not possible in plpgsql, but you can write plperl function, and later use
it in plpgsql triggers.
Regards,
Dmitry
--
Sen
hubert depesz lubaczewski wrote:
On Tue, Mar 09, 2010 at 06:59:31PM +0100, Pavel Stehule wrote:
2010/3/9 strk :
How can a pl/pgsql trigger change the
values of dynamic fields in NEW record ?
By "dynamic" I mean that the field name
is a variable in the trigger context.
I've been told
On Tue, Mar 09, 2010 at 06:59:31PM +0100, Pavel Stehule wrote:
> 2010/3/9 strk :
> > How can a pl/pgsql trigger change the
> > values of dynamic fields in NEW record ?
> >
> > By "dynamic" I mean that the field name
> > is a variable in the trigger context.
> >
> > I've been told it's easy to do wi
2010/3/9 strk :
> On Tue, Mar 09, 2010 at 06:59:31PM +0100, Pavel Stehule wrote:
>> 2010/3/9 strk :
>> > How can a pl/pgsql trigger change the
>> > values of dynamic fields in NEW record ?
>> >
>> > By "dynamic" I mean that the field name
>> > is a variable in the trigger context.
>> >
>> > I've be
On Tue, Mar 09, 2010 at 06:59:31PM +0100, Pavel Stehule wrote:
> 2010/3/9 strk :
> > How can a pl/pgsql trigger change the
> > values of dynamic fields in NEW record ?
> >
> > By "dynamic" I mean that the field name
> > is a variable in the trigger context.
> >
> > I've been told it's easy to do wi
2010/3/9 strk :
> How can a pl/pgsql trigger change the
> values of dynamic fields in NEW record ?
>
> By "dynamic" I mean that the field name
> is a variable in the trigger context.
>
> I've been told it's easy to do with pl/perl but
> I'd like to delive a pl/pgsql solution to have
> less dependen
How can a pl/pgsql trigger change the
values of dynamic fields in NEW record ?
By "dynamic" I mean that the field name
is a variable in the trigger context.
I've been told it's easy to do with pl/perl but
I'd like to delive a pl/pgsql solution to have
less dependencies.
Thanks in advance.
--str
41 matches
Mail list logo
