On 17.03.10 4:08 , Merlin Moncure wrote:
On Tue, Mar 16, 2010 at 5:53 PM, Florian
Pflugfgp.phlo@gmail.com wrote:
which returns the field namedfield from the record. The
expected field type is specified by providing a default value
indefval of the expected type. Since that argument's type
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
On Tue, Mar 16, 2010 at 5:53 PM, Florian Pflug fgp.phlo@gmail.com wrote:
which returns the field named field from the record. The expected
field type is specified by providing a default value in defval of the
expected type. Since that argument's type is ANYELEMENT, just like the
return
On Sat, Mar 13, 2010 at 1:38 PM, Tom Lane t...@sss.pgh.pa.us 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
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 Mon, Mar 15, 2010 at 10:02 AM, Andrew Dunstan and...@dunslane.net 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
Merlin Moncure mmonc...@gmail.com writes:
On Mon, Mar 15, 2010 at 10:02 AM, Andrew Dunstan and...@dunslane.net 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
On Mon, Mar 15, 2010 at 11:37 AM, Tom Lane t...@sss.pgh.pa.us 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
Merlin Moncure mmonc...@gmail.com writes:
On Mon, Mar 15, 2010 at 11:37 AM, Tom Lane t...@sss.pgh.pa.us 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
On Mon, Mar 15, 2010 at 12:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
On Mon, Mar 15, 2010 at 11:37 AM, Tom Lane t...@sss.pgh.pa.us wrote:
If we make the implementation be such that (rec-field)::foo forces
a runtime cast to foo (rather than throwing an
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.
Andrew Dunstan and...@dunslane.net 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
On Sat, Mar 13, 2010 at 11:40 AM, Tom Lane t...@sss.pgh.pa.us 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
2010/3/13 Tom Lane t...@sss.pgh.pa.us:
Andrew Dunstan and...@dunslane.net 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
Merlin Moncure mmonc...@gmail.com writes:
On Sat, Mar 13, 2010 at 11:40 AM, Tom Lane t...@sss.pgh.pa.us 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
2010/3/13 Tom Lane t...@sss.pgh.pa.us:
Merlin Moncure mmonc...@gmail.com writes:
On Sat, Mar 13, 2010 at 11:40 AM, Tom Lane t...@sss.pgh.pa.us 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
Merlin Moncure mmonc...@gmail.com 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
On Sat, Mar 13, 2010 at 12:18:32PM -0500, Tom Lane wrote:
Merlin Moncure mmonc...@gmail.com 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
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
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're
On Thu, Mar 11, 2010 at 11:24 PM, Alvaro Herrera
alvhe...@commandprompt.com 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
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 s...@keybit.net:
How can a pl/pgsql trigger change the
values of dynamic fields in NEW record ?
By dynamic I mean
2010/3/12 David Fetter da...@fetter.org:
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 s...@keybit.net:
How can a pl/pgsql trigger change the
values of dynamic
On Fri, Mar 12, 2010 at 07:35:41PM +0100, Pavel Stehule wrote:
2010/3/12 David Fetter da...@fetter.org:
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
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 da...@fetter.org:
This is, by the way, an excellent argument for including hstore in
core in 9.1. :)
I like it - but it looking
2010/3/12 strk s...@keybit.net:
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 da...@fetter.org:
This is, by the way, an excellent argument for including hstore in
core in 9.1. :)
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 da...@fetter.org:
This is, by the way, an excellent argument for including hstore in
core in 9.1. :)
I
On Fri, Mar 12, 2010 at 3:01 PM, Boszormenyi Zoltan z...@cybertec.at 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
Merlin Moncure írta:
On Fri, Mar 12, 2010 at 3:01 PM, Boszormenyi Zoltan z...@cybertec.at 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 4:24 PM, Boszormenyi Zoltan z...@cybertec.at wrote:
Merlin Moncure írta:
On Fri, Mar 12, 2010 at 3:01 PM, Boszormenyi Zoltan z...@cybertec.at wrote:
What's wrong with UPDATE foo SET (foo) = (NEW); ?
amen brother! :-)
I say though, since you can do:
SELECT foo
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
--
Sent via
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
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 da...@fetter.org http://fetter.org/
On Wed, Mar 10, 2010 at 7:50 AM, Andrew Dunstan and...@dunslane.net wrote:
2010/3/9 strk s...@keybit.net:
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
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 EXECUTE
On Tue, Mar 09, 2010 at 06:59:31PM +0100, Pavel Stehule wrote:
2010/3/9 strk s...@keybit.net:
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
hubert depesz lubaczewski wrote:
On Tue, Mar 09, 2010 at 06:59:31PM +0100, Pavel Stehule wrote:
2010/3/9 strk s...@keybit.net:
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.
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.
2010/3/9 strk s...@keybit.net:
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
On Tue, Mar 09, 2010 at 06:59:31PM +0100, Pavel Stehule wrote:
2010/3/9 strk s...@keybit.net:
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
2010/3/9 strk s...@keybit.net:
On Tue, Mar 09, 2010 at 06:59:31PM +0100, Pavel Stehule wrote:
2010/3/9 strk s...@keybit.net:
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.
41 matches
Mail list logo
