On Sat, 2010-03-13 at 15:29 -0800, Josh Berkus wrote:
> > It's also my 3rd choice of solution behind fine-grained lock conflicts
> > (1st) which would avoid many issues and master/standby in lock step
> > (2nd).
>
> Yeah, I just can't imagine you hunting down all of the corner cases for
> fine-gr
On Sat, Mar 13, 2010 at 12:10 PM, Tom Lane wrote:
> Bruce Momjian writes:
>> Tom Lane wrote:
>>> This is making things worse, not better. You have just changed the
>>> behavior, and not in a good way. Formerly these were no-ops on
>>> a unix socket connection, and now they can throw errors.
>
>
> The list has been reduced greatly in the past week. What about HS/SR
> open items?
I'd like to see vacuum_defer_cleanup_age added to the "Archive" section
of postgresql.conf, and add it to the docs (I'll write something this
week). I'd like to get rid of the associated hint-bits bogus error
m
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:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> This is making things worse, not better. You have just changed the
> >> behavior, and not in a good way. Formerly these were no-ops on
> >> a unix socket connection, and now they can throw errors.
>
> > Is this the proper way to f
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
Bruce Momjian writes:
> Tom Lane wrote:
>> This is making things worse, not better. You have just changed the
>> behavior, and not in a good way. Formerly these were no-ops on
>> a unix socket connection, and now they can throw errors.
> Is this the proper way to fix the issue? Patch attached.
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> This makes the function *not* like the other two, rather than
> >> improving consistency.
>
> > Well, it makes it like some of the existing functions, but not like
> > others. This applied patch fixes them all.
>
> This is making
On Fri, 2010-03-12 at 22:28 -0500, Bruce Momjian wrote:
> Where are we in getting to beta1? I know people are looking to me for
> 9.0 release notes and I will have them done in about a week, but what
> about open issues? I don't see many on the main 9.0 open items page:
>
> http://wiki.po
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
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > Tom Lane wrote:
> > >> This makes the function *not* like the other two, rather than
> > >> improving consistency.
> >
> > > Well, it makes it like some of the existing functions, but not like
> > > others. This applied patch
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> This makes the function *not* like the other two, rather than
> >> improving consistency.
>
> > Well, it makes it like some of the existing functions, but not like
> > others. This applied patch fixes them all.
>
> This is making
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
Bruce Momjian writes:
> Tom Lane wrote:
>> This makes the function *not* like the other two, rather than
>> improving consistency.
> Well, it makes it like some of the existing functions, but not like
> others. This applied patch fixes them all.
This is making things worse, not better. You hav
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
Tom Lane wrote:
> Bruce Momjian writes:
> > Jaime Casanova wrote:
> >> but in pq_setkeepalivesinterval() the #DEFINE is after the
> >> conditional, doesn't seems to affect anything but for consistency with
> >> the other two :)
>
> > Thanks, applied.
>
> This makes the function *not* like the ot
Bruce Momjian writes:
> Jaime Casanova wrote:
>> but in pq_setkeepalivesinterval() the #DEFINE is after the
>> conditional, doesn't seems to affect anything but for consistency with
>> the other two :)
> Thanks, applied.
This makes the function *not* like the other two, rather than
improving con
Jaime Casanova wrote:
> Hi,
>
> In 2 of 3 pq_setkeepalives* functions we have the #DEFINE involving
> even this conditional:
> """
> if (port == NULL || IS_AF_UNIX(port->laddr.addr.ss_family))
> return STATUS_OK;
> """
>
> but in pq_setkeepalivesinterval() the #DEFINE is after the
> c
Applied.
---
Bruce Momjian wrote:
> Andrew Dunstan wrote:
> >
> >
> > Bruce Momjian wrote:
> > > + /* If it was 'invalid authorization', add .pgpass mention */
> > > + if (conn->dot_pgpass_used && conn->pas
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.
24 matches
Mail list logo
