>
> 4. What about functions whose output typmod should depend on the input
> typmod(s)? I mentioned earlier the example that concatenation of
> varchar(M) and varchar(N) should produce varchar(M+N). We could possibly
> punt on this for the time being; supporting only fixed output typmods for
> n
>
> So I guess really can't get worked up about the idea of propagating
> this information through the type system. Even suppose we eventually
> take the steps you suggesting and make it so that varchar(30) ||
> varchar(40) yields varchar(70). What good is that?
I see main sense in enhancing war
2009/11/17 Dimitri Fontaine :
> Le 17 nov. 2009 à 20:33, Tom Lane a écrit :
>>> We could to talk about it now. We are not hurry. But I would to see
>>> some progress in this area in next two months. This patch is simple
>>> and doesn't create any new rules or doesn't change behave.
>>
>> What do yo
2009/11/17 Robert Haas :
> On Tue, Nov 17, 2009 at 5:34 PM, Greg Smith wrote:
>> Pavel Stehule wrote:
>>>
>>> I don't wont to apply these patches tomorrow, I don't sending these
>>> patches for last moment. If I have to wait one weak or two weeks, ok.
>>> Declare it. I'll respect it. But actually
2009/11/17 Joshua D. Drake :
> On Tue, 2009-11-17 at 15:40 -0600, Kevin Grittner wrote:
>> Pavel Stehule wrote:
>>
>> > I never sent these (last two) patches to THIS commitfest. Is it
>> > clean?
>>
>> I'm sure it would be much appreciated, and help to alleviate the
>> frustration and burnout of s
"Albe Laurenz" wrote:
> Heikki Linnakangas wrote:
> > I think it would better to add an explicit "isencrypted" parameter to
> > the check_password_hook function, rather than require the module to do
> > isMD5 on the password.
>
> I agree on the second point, and I changed the patch accordingly.
Marko Tiikkaja wrote:
> this looks like a mistake:
> partinfo = (PartitionInfo *) malloc(ntups * sizeof(PartitionInfo));
Oops, it should be "p"alloc. Thanks.
> Maybe we should use something like
> PARTITION bar VALUES OPERATOR 0
> when the user specifies the operator?
I think we could have rea
Jaime Casanova wrote:
> > * If a table with the same name already exists when a partition
> > is created, the table is re-used as partition. This behavior
> > is required for pg_dump to be simple.
>
> i guess the table must be empty, if not we should be throw an error...
> and i actually pr
Andrew Dunstan wrote:
> Itagaki Takahiro wrote:
> > I don't want user to check the encoding of scripts before executing --
> > it is far from fail-safe.
>
> That's what we require in all other cases. Why should UTF8 be special?
No. I didn't think about UTF-8 nor BOM in that point.
I assumed w
Simon Riggs wrote:
> Why not just wait until we have a whole patch and then apply?
"A whole patch" can be written by many contributers instead of only
one person, no? I think we need to split works for partitioning
into serveral parts to encourage developing it. I just did one of
the parts, "s
Itagaki Takahiro wrote:
I don't want user to check the encoding of scripts before executing --
it is far from fail-safe.
That's what we require in all other cases. Why should UTF8 be special?
If I have a script in Latin1 and Postgres thinks it's UTF8 it will
probably explode. Same for
> "hernan" == hernan gonzalez writes:
>> Perhaps the OP should explain exactly what real-world problems
>> he's trying to solve. As noted in the discussion you linked,
>> there's not a lot of enthusiasm around here for getting closer to
>> the spec's datetime handling simply because it's
Marko Tiikkaja wrote:
> Jaime Casanova wrote:
> >> PARTITION name VALUES LESS THAN { range_upper | MAXVALUE }
> >>| PARTITION name VALUES IN ( list_value [,...] | DEFAULT )
> >
> > i remember someone making a comment about actually using operators
> > instead of LESS THEN and family
>
On Sat, Nov 14, 2009 at 2:27 PM, Jeff Davis wrote:
> New patches attached.
Forgive me if this is discussed before, but why does this store the
strategy numbers of the relevant operators instead of the operators
themselves? It seems like this could lead to surprising behavior if
the user modifies
Andrew Dunstan wrote:
> Itagaki Takahiro wrote:
> > Multi-byte scripts
> > without encoding are always dangerous whether BOM is present or not.
> > I'd say we can always throw an error when we find queries that contain
> > multi-byte characters if no prior encoding declaration.
>
> You will br
Peter Eisentraut wrote:
> Together, that should cover a lot of cases. Not perfect, but far from
> useless.
For Japanese users on Windows, the client encoding are always set to SJIS
because of the restriction of cmd.exe. But the script file can be written
in UTF8 with BOM. I don't think we shou
ec (15a)
"
u8=#
Seems there's something about the current version of the dictionary that
we don't like. I used sjp-ispell-pl-20091117-src.tar.bz2 ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
Joshua Tolley wrote:
+ plperl_call_data *save_call_data = current_call_data;
+ boololdcontext = trusted_context;
+
+ if (SPI_connect() != SPI_OK_CONNECT)
+ elog(ERROR, "could not connect to SPI manager");
...
+ current_call_data = (plperl_call
Hi,
I noticed that some example functions don't contain the magic block and that
leads to error while loading those examples in 8.2 or later.
Attached is a patch that adds it. I also add some missing header file. Don't
have a strong opinion about backpatching it or not.
--
Euler Taveira de O
On Tue, Nov 17, 2009 at 06:05:19PM -0500, Andrew Dunstan wrote:
>
>
> Alexey Klyukin wrote:
>>
>> I've noticed that the patch doesn't install current_call_data before calling
>> plperl_call_perl_func, although it saves and restores its previous value.
>> This breaks spi code, which relies on curr
Wojciech Knapik escreveu:
>
> Euler Taveira de Oliveira wrote:
>
>>> PS. This issue is not related to the loading time of dictionaries, or
>>> calls to ts_headline for results that won't be displayed.
>>
>> So what? Could you post the profiling of that query?
>
I was talking about gprof (--enabl
On Tue, Nov 17, 2009 at 7:46 PM, Tom Lane wrote:
> Robert Haas writes:
>> So I guess really can't get worked up about the idea of propagating
>> this information through the type system. Even suppose we eventually
>> take the steps you suggesting and make it so that varchar(30) ||
>> varchar(40)
On Tue, Nov 17, 2009 at 4:31 PM, Simon Riggs wrote:
> On Thu, 2009-10-29 at 11:15 +0900, Itagaki Takahiro wrote:
>
>> I think syntax support is a good start.
>
> I don't see a syntax-only patch as being any use at all to this
> community.
>
> We go to enormous lengths in other areas to never allow
Robert Haas escreveu:
> On Tue, Nov 17, 2009 at 6:39 PM, Euler Taveira de Oliveira
> wrote:
>> Alex Hunsaker escreveu:
>>> BTW anyone know how to escape < and > for google?
>>>
>> You can escape < and > using < and >, respectively.
>
> Searching for
Robert Haas writes:
> So I guess really can't get worked up about the idea of propagating
> this information through the type system. Even suppose we eventually
> take the steps you suggesting and make it so that varchar(30) ||
> varchar(40) yields varchar(70). What good is that? Why would anyo
"Kevin Grittner" writes:
> hernan gonzalez wrote:
>> I believe that this distinction between two realms: one related to
>> (say) "physical time" and the other to (say) "civil date-time", is
>> the key to put some order... conceptually, at least (I'm not
>> speaking about feasibility for now).
>
On Tue, Nov 17, 2009 at 6:39 PM, Euler Taveira de Oliveira
wrote:
> Alex Hunsaker escreveu:
>> BTW anyone know how to escape < and > for google?
>>
> You can escape < and > using < and >, respectively.
Searching for
On Tue, Nov 17, 2009 at 6:01 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> Apart from all these it's not clear to me what the major benefits of
>> doing this would be. I'd like an explanation of that to start with.
>
> Well, aside from the issue about making "anyelement" more powerful
> (which
Euler Taveira de Oliveira wrote:
PS. This issue is not related to the loading time of dictionaries, or
calls to ts_headline for results that won't be displayed.
So what? Could you post the profiling of that query?
Polish:
http://pastie.textmate.org/private/8lhmnbvde43lfjoxc52r1q
English:
h
Wojciech Knapik escreveu:
> PS. This issue is not related to the loading time of dictionaries, or
> calls to ts_headline for results that won't be displayed.
>
So what? Could you post the profiling of that query?
--
Euler Taveira de Oliveira
http://www.timbira.com/
--
Sent via pgsql-hacke
Hello
This has been discussed in #postgresql and posted to -performance a
couple days ago, but no solution has been found. The discussion can be
found here:
http://archives.postgresql.org/pgsql-performance/2009-11/msg00162.php
I just finished implementing a "search engine" for my site an
Robert Haas wrote:
This expresses my feelings on the topic exactly, and perhaps merits
inclusion in a Wiki page someplace. Maybe we need to have a wiki page
on commitfest rules & expectations.
I put a note at
http://wiki.postgresql.org/wiki/Submitting_a_Patch#Submission_timing
which seems t
Alex Hunsaker escreveu:
> BTW anyone know how to escape < and > for google?
>
You can escape < and > using < and >, respectively.
--
Euler Taveira de Oliveira
http://www.timbira.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
Hello
This has been discussed in #postgresql and posted to -performance a
couple days ago, but no solution has been found. The discussion can be
found here:
http://archives.postgresql.org/pgsql-performance/2009-11/msg00162.php
I just finished implementing a "search engine" for my site and fo
Alexey Klyukin wrote:
I've noticed that the patch doesn't install current_call_data before calling
plperl_call_perl_func, although it saves and restores its previous value. This
breaks spi code, which relies on current_call_data->prodesc, i.e.:
postgres=# DO $$ $result = spi_exec_query("sel
Andrew Dunstan writes:
> Apart from all these it's not clear to me what the major benefits of
> doing this would be. I'd like an explanation of that to start with.
Well, aside from the issue about making "anyelement" more powerful
(which could be done in other ways), I can think of:
If we don't
On Tue, Nov 17, 2009 at 5:34 PM, Greg Smith wrote:
> Pavel Stehule wrote:
>>
>> I don't wont to apply these patches tomorrow, I don't sending these
>> patches for last moment. If I have to wait one weak or two weeks, ok.
>> Declare it. I'll respect it. But actually I respecting all rules, what
>>
Le 17 nov. 2009 à 20:33, Tom Lane a écrit :
>> We could to talk about it now. We are not hurry. But I would to see
>> some progress in this area in next two months. This patch is simple
>> and doesn't create any new rules or doesn't change behave.
>
> What do you mean it doesn't change the behavio
On Nov 9, 2009, at 6:07 PM, Joshua Tolley wrote:
>
> Ok, updated patch attached. As far as I know, this completes all outstanding
> issues:
>
> 1) weird comment in plperl.c is corrected and formatted decently
> 2) plperlu vs. plperl actually works (thanks again, Andrew)
> 3) docs included
> 4) r
On Wed, Nov 18, 2009 at 09:35:35AM +1100, Brendan Jurd wrote:
> 2009/11/17 Joshua Tolley :
> > On Sun, Nov 15, 2009 at 12:10:33PM +1100, Brendan Jurd wrote:
> >> I noticed that there was a fairly large amount of bogus/inconsistent
> >> whitespace
> ...
> >
> > Thanks -- I tend to forget whitespace
2009/11/17 Joshua Tolley :
> On Sun, Nov 15, 2009 at 12:10:33PM +1100, Brendan Jurd wrote:
>> I noticed that there was a fairly large amount of bogus/inconsistent
>> whitespace
...
>
> Thanks -- I tend to forget whitespace :)
>
>> In the documentation you refer to this feature as "inline functions"
On Thu, 2009-10-29 at 11:15 +0900, Itagaki Takahiro wrote:
> I think syntax support is a good start.
I don't see a syntax-only patch as being any use at all to this
community.
We go to enormous lengths in other areas to never allow patches with
restrictions. Why would we allow a patch that is es
Pavel Stehule wrote:
I don't wont to apply these patches tomorrow, I don't sending these
patches for last moment. If I have to wait one weak or two weeks, ok.
Declare it. I'll respect it. But actually I respecting all rules, what
I know.
If you're sending stuff intended for the next CommitFest
hernan gonzalez wrote:
> I believe that this distinction between two realms: one related to
> (say) "physical time" and the other to (say) "civil date-time", is
> the key to put some order... conceptually, at least (I'm not
> speaking about feasibility for now). This is the approach of some
> Da
Tom Lane wrote:
Pavel submitted a patch to add typmods to function declarations, but there
was no prior design discussion and it desperately needs some. Let me try
to summarize the issues that seem to need agreement.
[excellent summary of problem areas snipped]
Unless we have consensus
On Nov 17, 2009, at 9:15 AM, Andrew Dunstan wrote:
> Indeed. I once suggested only half jokingly that we should have a "Coder of
> the month" award.
I suggest that it be named "The Tom Lane" award, and disqualify Tom from
winning (sorry Tom). ;-)
David
--
Sent via pgsql-hackers mailing list (
On Tue, 2009-11-17 at 15:40 -0600, Kevin Grittner wrote:
> Pavel Stehule wrote:
>
> > I never sent these (last two) patches to THIS commitfest. Is it
> > clean?
>
> I'm sure it would be much appreciated, and help to alleviate the
> frustration and burnout of some other contributors, if you cou
Pavel submitted a patch to add typmods to function declarations, but there
was no prior design discussion and it desperately needs some. Let me try
to summarize the issues that seem to need agreement.
The proposed patch allows optional typmods to be attached to the declared
argument and result ty
Pavel Stehule wrote:
> I never sent these (last two) patches to THIS commitfest. Is it
> clean?
Counting the "In Progress" commitfest and the two preceding ones, you
have submitted nine patches and contributed to the review of none.
Surely you noticed recent threads about how the review and c
2009/11/17 Joshua D. Drake :
> On Tue, 2009-11-17 at 14:33 -0600, Kevin Grittner wrote:
>> Pavel Stehule wrote:
>> > 2009/11/17 Robert Haas :
>>
>> >> This is now the fourth patch you've submitted since the start of
>> >> the CommitFest...
>> >>
>> >
>> > These patches are for next commitfest. Wha
> Perhaps the OP should explain exactly what real-world problems he's
> trying to solve. As noted in the discussion you linked, there's not
> a lot of enthusiasm around here for getting closer to the spec's
> datetime handling simply because it's the spec; that part of the spec
> is just too broke
On Tue, 2009-11-17 at 14:33 -0600, Kevin Grittner wrote:
> Pavel Stehule wrote:
> > 2009/11/17 Robert Haas :
>
> >> This is now the fourth patch you've submitted since the start of
> >> the CommitFest...
> >>
> >
> > These patches are for next commitfest. What I know, the current
> > commitfest
2009/11/17 Kevin Grittner :
> Pavel Stehule wrote:
>> 2009/11/17 Robert Haas :
>
>>> This is now the fourth patch you've submitted since the start of
>>> the CommitFest...
>>>
>>
>> These patches are for next commitfest. What I know, the current
>> commitfest is closed for new patches. Is it ok?
>
Pavel Stehule wrote:
> 2009/11/17 Robert Haas :
>> This is now the fourth patch you've submitted since the start of
>> the CommitFest...
>>
>
> These patches are for next commitfest. What I know, the current
> commitfest is closed for new patches. Is it ok?
Until this moment I was unconvinced
2009/11/17 Pavel Stehule :
> 2009/11/17 Robert Haas :
>> On Tue, Nov 17, 2009 at 3:04 PM, Pavel Stehule
>> wrote:
>>> Hello,
>>>
>>> this small patch add missing USING clause to OPEN FOR EXECUTE statement
>>> + cleaning part of exec_stmt_open function
>>>
>>>
>>> see http://archives.postgresql.or
2009/11/17 Robert Haas :
> On Tue, Nov 17, 2009 at 3:04 PM, Pavel Stehule
> wrote:
>> Hello,
>>
>> this small patch add missing USING clause to OPEN FOR EXECUTE statement
>> + cleaning part of exec_stmt_open function
>>
>>
>> see http://archives.postgresql.org/pgsql-hackers/2009-11/msg00713.php
>
On Tue, Nov 17, 2009 at 3:04 PM, Pavel Stehule wrote:
> Hello,
>
> this small patch add missing USING clause to OPEN FOR EXECUTE statement
> + cleaning part of exec_stmt_open function
>
>
> see http://archives.postgresql.org/pgsql-hackers/2009-11/msg00713.php
This is now the fourth patch you've s
2009/11/17 Kevin Grittner :
> Pavel Stehule wrote:
>
>> sorry, it's problem in my english
>
> In hopes that it may help overcome the language barrier if someone
> restates the issue in different words, I'll echo Tom's concerns, which
> I share.
>
>> This cannot change an behave of older applicatio
Pavel Stehule wrote:
> sorry, it's problem in my english
In hopes that it may help overcome the language barrier if someone
restates the issue in different words, I'll echo Tom's concerns, which
I share.
> This cannot change an behave of older applications.
Agreed. That's not the problem.
Jaime Casanova wrote:
* If a table with the same name already exists when a partition
is created, the table is re-used as partition. This behavior
is required for pg_dump to be simple.
i guess the table must be empty, if not we should be throw an error...
and i actually prefer some more
Hello,
this small patch add missing USING clause to OPEN FOR EXECUTE statement
+ cleaning part of exec_stmt_open function
see http://archives.postgresql.org/pgsql-hackers/2009-11/msg00713.php
Regards
Pavel Stehule
*** ./doc/src/sgml/plpgsql.sgml.orig 2009-11-13 23:43:39.0 +0100
--- ./do
Tom Lane escribió:
> George Gensure writes:
> > I've put together a small patch to provide a schema name in an fk
> > violation in deference to the todo item "Report the schema along table
> > name in a referential failure error message"
>
> This is not the way forward; if it were, we would have
2009/11/17 Tom Lane :
> Pavel Stehule writes:
>> 2009/11/17 Tom Lane :
>>> My point is that if we release 8.5 with these semantics (which as far
>>> as I can tell were not designed, but just fell out of what made for the
>>> shortest patch) then we'll be stuck with them thereafter.
>
>> We could t
On Thu, Nov 12, 2009 at 5:54 AM, Itagaki Takahiro
wrote:
> I added psql and pg_dump support to Partitioning Syntax patch.
> Paritioning information can be retrieved with a new system function
> pg_get_partitiondef(parentRelid). Both psql and pg_dump use it.
>
i haven't seen the patch but:
>
> *
Hi,
I'm reviewing your patch. The patch applies without problems and the
feature works as advertised. I have yet to look at the code in detail,
but it looks sane and seems to work. However, this looks like a mistake:
partinfo = (PartitionInfo *) malloc(ntups * sizeof(PartitionInfo));
or am I
Pavel Stehule writes:
> 2009/11/17 Tom Lane :
>> My point is that if we release 8.5 with these semantics (which as far
>> as I can tell were not designed, but just fell out of what made for the
>> shortest patch) then we'll be stuck with them thereafter.
> We could to talk about it now. We are no
Sergey Konoplev escribió:
> On Mon, Nov 16, 2009 at 9:56 PM, Alvaro Herrera
> wrote:
> > Sergey Konoplev escribió:
> >
> >> I tried to get locks with this queries
> >
> > Did you try pg_locks?
> >
>
> I tried monitor locks with pgrowlocks. Isn't it better way? If it
> isn't what points should I p
2009/11/17 Tom Lane :
> Pavel Stehule writes:
>> 2009/11/17 Tom Lane :
>>> There are other issues but these are the ones I think we'd need to
>>> resolve before not after putting in function typmods. It'd be
>>> extremely painful and non-backwards-compatible to change our minds
>>> later about fu
Pavel Stehule writes:
> 2009/11/17 Tom Lane :
>> There are other issues but these are the ones I think we'd need to
>> resolve before not after putting in function typmods. Â It'd be
>> extremely painful and non-backwards-compatible to change our minds
>> later about function identity or coercion
Andrew Dunstan writes:
> Well, it might be a good idea to provide at least some support in libpq.
> Making each client do it from scratch seems a bit inefficient.
Encoding conversion seems far outside libpq's charter, and as for
"from scratch" there are other libraries for that.
2009/11/17 Tom Lane :
> Pavel Stehule writes:
>> 2009/11/17 Tom Lane :
>>> If the only immediate benefit we'd get is multiple anyelement types,
>>> I think we'd be much better advised to just create a few separate
>>> types for that. Function typmods are a big can of worms and we should
>>> not lo
Tom Lane wrote:
Andrew Dunstan writes:
Peter Eisentraut wrote:
Well, someone could implement UTF-16 or UTF-whatever as client encoding.
But I have not heard of any concrete proposals about that.
Doesn't the nul byte problem make that seriously hard?
Just about imp
Andrew Dunstan writes:
> Peter Eisentraut wrote:
>> Well, someone could implement UTF-16 or UTF-whatever as client encoding.
>> But I have not heard of any concrete proposals about that.
> Doesn't the nul byte problem make that seriously hard?
Just about impossible. It would require a protocol
Pavel Stehule writes:
> 2009/11/17 Tom Lane :
>> If the only immediate benefit we'd get is multiple anyelement types,
>> I think we'd be much better advised to just create a few separate
>> types for that. Function typmods are a big can of worms and we should
>> not lock ourselves into a half-bake
> -Original Message-
> From: Andrew Dunstan [mailto:and...@dunslane.net]
> Sent: Tuesday, November 17, 2009 9:15 AM
> To: Peter Eisentraut
> Cc: Chuck McDevitt; Itagaki Takahiro; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] UTF8 with BOM support in psql
>
>
>
> Peter Eisentraut
Peter Eisentraut wrote:
On tis, 2009-11-17 at 00:59 -0800, Chuck McDevitt wrote:
Or is there a plan to read and convert the UTF-16 or UTF-32 to UTF-8,
so psql and PostgreSQL understand it?
(BTW, that would actually be nice on Windows, where UTF-16 is common).
Well, someone could impl
> -Original Message-
> From: Peter Eisentraut [mailto:pete...@gmx.net]
> Sent: Tuesday, November 17, 2009 9:05 AM
> To: Chuck McDevitt
> Cc: Itagaki Takahiro; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] UTF8 with BOM support in psql
>
> On tis, 2009-11-17 at 00:59 -0800, Chuck Mc
On tis, 2009-11-17 at 00:59 -0800, Chuck McDevitt wrote:
> Or is there a plan to read and convert the UTF-16 or UTF-32 to UTF-8,
> so psql and PostgreSQL understand it?
> (BTW, that would actually be nice on Windows, where UTF-16 is common).
Well, someone could implement UTF-16 or UTF-whatever as
On tis, 2009-11-17 at 09:31 +0900, Itagaki Takahiro wrote:
> Peter Eisentraut wrote:
>
> > OK, I think the consensus here is:
> > - Eat BOM at beginning of file (as you implemented)
> > - Only when client encoding is UTF-8 --> please fix that
>
> Are they AND condition? If so, this patch will be
Valtonen, Hannu wrote:
> I couldn't figure out how to get added files to show in git diff ...
git add
git add -u # to include modified files in the index
git diff --cached
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hacker
Hi,
The attached patch adds support for DO clause in plpythonu. It was
heavily inspired by the plperl and plpgsql inline handler code.
I couldn't figure out how to get added files to show in git diff so the
two files that this patch adds: expected/plpython_do.out and
expected/plpython_do.sql
Emmanuel Cecchet writes:
> Tom Lane wrote:
>> Cache? Why do you need a cache for COPY?
> Actually the cache is only activated if you use the partitioning option.
> It is just a list of oids of child tables where tuples were inserted.
Umm ... why is that useful enough to be cached?
> Why do I
On Mon, Nov 16, 2009 at 10:17 PM, Andres Freund wrote:
> On Wednesday 11 November 2009 18:50:46 Sergey Konoplev wrote:
>> Hello community,
>>
>>
>> Second time after migration 8.3.7 --> 8.4.1 I was caught by this
>> problem. Migration was 8 days ago.
>> (note, I never seen such situation on 8.3)
>
>
> Can you show us the non-commented settings from your postgresql.conf?
Working postgresql.conf http://pastie.org/702748
>
> Can you show us what the vmstat output looks like when everything is
> running normally? It looks like the blocks out are pretty high, but I
> don't know how that compar
On Mon, Nov 16, 2009 at 9:56 PM, Alvaro Herrera
wrote:
> Sergey Konoplev escribió:
>
>> I tried to get locks with this queries
>
> Did you try pg_locks?
>
I tried monitor locks with pgrowlocks. Isn't it better way? If it
isn't what points should I pay attention with pg_lock?
I've just write the
Tom Lane wrote:
Emmanuel Cecchet writes:
Actually the list is supposed to stay around between statement
executions. You don't want to restart with a cold cache at every
statement so I really want this structure to stay in memory at a more
global level.
Cache? Why do you need a cach
Robert Haas writes:
> One random thought - I am not aware that we currently have a "time
> zone" type in which to store a time zone in. Is there any value in
> having such a thing vs. just using varchar?
The main potential advantage seems to be faster lookup of the zone's
associated data ... but
Emmanuel Cecchet writes:
> Actually the list is supposed to stay around between statement
> executions. You don't want to restart with a cold cache at every
> statement so I really want this structure to stay in memory at a more
> global level.
Cache? Why do you need a cache for COPY? Repeat
On Tue, Nov 17, 2009 at 03:54, Marko Tiikkaja
wrote:
>> Also, after reading through the previous threads; it was not
>> immediately obvious that you dealt with
>> http://archives.postgresql.org/pgsql-hackers/2009-10/msg00566.php by
>> only allowing selects or values at the top level of with.
>
> T
Peter Eisentraut writes:
> I think I could support using the presence of the BOM as a fall-back
> indicator of encoding in absence of any other declaration. It seems to
> me, however, that the description above ignores the existence of
> encodings other than SQL_ASCII and UTF8.
Yeah. This entir
On Tue, Nov 17, 2009 at 10:21 AM, hernan gonzalez wrote:
> Are there any plans to (is anybody working on) implement better
> timezone support in postgresql
> for 8.5 ? Specifically, store the timezone info -instead of just the
> timestamp as UTC ?
> http://wiki.postgresql.org/wiki/Todo#Dates_and_T
Robert Haas wrote:
> On Mon, Nov 16, 2009 at 11:07 AM, Kevin Grittner
> wrote:
>> Tom Lane wrote:
>>
>>> I agree with Heikki that it would be better not to commit as long
>>> as any clear showstoppers remain unresolved.
>>
>> I agree that it would be better not to commit as long as any of the
>>
Tom Lane wrote:
Emmanuel Cecchet writes:
Tom Lane wrote:
This looks like the patch is trying to create a data structure in a
memory context that's not sufficiently long-lived for the use of the
structure. If you do this in a non-cassert build, it will seem to
work, some of the time, i
Are there any plans to (is anybody working on) implement better
timezone support in postgresql
for 8.5 ? Specifically, store the timezone info -instead of just the
timestamp as UTC ?
http://wiki.postgresql.org/wiki/Todo#Dates_and_Times
Hernán J. González
--
Sent via pgsql-hackers mailing list (p
2009/11/17 Tom Lane :
> Dimitri Fontaine writes:
>> The idea to add support for typmods in function signatures came from the
>> need to have more than one anyelement at a time in a function, and Pavel
>> proposed that we spell that anyelement(0) and anyelement(1) e.g.
>
>> Is that how we want to s
Emmanuel Cecchet writes:
> Tom Lane wrote:
>> This looks like the patch is trying to create a data structure in a
>> memory context that's not sufficiently long-lived for the use of the
>> structure. If you do this in a non-cassert build, it will seem to
>> work, some of the time, if the memory i
Tom Lane wrote:
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
Program received signal SIGSEGV, Segmentation fault.
0x0819368b in route_tuple_to_child (parent_relation=0xb5d93040,
tuple=0x873b08c, hi_options=0, parentResultRelInfo=0x871e204) at copy.c:1821
1821child_rel
"Greg Sabino Mullane" writes:
> Perhaps you mean the discussion from
> July 6, 2009 started by Robert Haas? That was approximately 8000
> messages ago, and no consensus was reached that I could find.
Precisely.
> So I'd like to respectfully ask the hackers to consider raising the
> default value
Dimitri Fontaine writes:
> The idea to add support for typmods in function signatures came from the
> need to have more than one anyelement at a time in a function, and Pavel
> proposed that we spell that anyelement(0) and anyelement(1) e.g.
> Is that how we want to solve it?
TBD, really. It wa
George Gensure writes:
> There's some tricky stuff in here to say the least. Doesn't look like
> param names are kept anywhere past the parser - gonna have to have it
> follow through a bunch of functions to reach
> parse_(fixed|variable)_parameters. The p_post_columnref_hook you
> alluded to wi
1 - 100 of 108 matches
Mail list logo
