On Tue, Mar 31, 2009 at 2:26 PM, Tom Lane wrote:
> Does anyone want to argue for keeping it the same? Or perhaps
> argue that a zero-element array is a more sensible result than
> a one-element array with one empty string? (It doesn't seem
> like it to me, but maybe somebody thinks so.)
>
My fi
Sorry for top-posting--blame apple.
Hm my first instinct was indeed to make it a zero-length array. I was
thinking of the input as a "list" and surely there are no elements in
a list which empty. I had to think a while until a length-1 array made
sense.
I suppose the thinking was string_t
Alvaro Herrera writes:
> ... However, on HEAD this is crashing for me, and it's right when plpython
> loads. Backtrace below.
Does plpython pass its regression tests for you (I'd suppose not)?
For me on Fedora 10 x86_64, CVS HEAD plus python 2.5.2 passes regression
but the given example still d
Tom Lane wrote:
Marko Kreen writes:
Or at least such roundabout effects should be commented -
"Ancient pointer here would still point to PGPROC struct".
Agreed, the comment should mention all of these possibilities.
Fixed.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.c
On Monday 30 March 2009 15:34:49 David Fetter wrote:
> On Mon, Mar 30, 2009 at 01:31:23PM -0400, Tom Lane wrote:
> > David Fetter writes:
> > > SELECT
> > > i,
> > > t,
> > > RANK() OVER (
> > > PARTITION BY i
> > > ORDER BY random()
> > > )
> > > FROM foo;
> > > ER
On Monday 30 March 2009 10:52:47 Bruce Momjian wrote:
> Robert Haas wrote:
> > On Mon, Mar 30, 2009 at 10:13 AM, Bruce Momjian wrote:
> > > Maybe the best we are going to do is to have any pattern supplied to
> > > \d* assume 'S' (include system objects). ?I actually have a patch that
> > > does t
On Tue, Mar 31, 2009 at 11:20 AM, Tom Lane wrote:
> A quick look at contrib/pgstattuple shows that it makes no effort
> whatsoever to avoid reading temp tables belonging to other sessions.
> So even if that wasn't Stuart's problem (and I'll bet it was), this
> is quite broken.
>
> There is no way
Alvaro Herrera writes:
> Tom Lane wrote:
>> Does plpython pass its regression tests for you (I'd suppose not)?
> Doh. Silly me. It does pass the regression tests, all six of them. I
> guess it's trying to load the unicode stuff that it crashes, not
> plpython itself ...
Hm, maybe we weren't t
On Mar 30, 2009, at 8:26 PM, Tom Lane wrote:
Does anyone want to argue for keeping it the same? Or perhaps
argue that a zero-element array is a more sensible result than
a one-element array with one empty string? (It doesn't seem
like it to me, but maybe somebody thinks so.)
Hrm. There seems
I wrote:
> ... what this sounds like is a
> problem with somebody fetching temporary-table blocks into shared memory
> (where they should never be), and then things going wrong after the
> owning backend drops the temp table (without having cleared out shared
> buffers, which it won't do because it
Tom Lane wrote:
> Alvaro Herrera writes:
> > ... However, on HEAD this is crashing for me, and it's right when plpython
> > loads. Backtrace below.
>
> Does plpython pass its regression tests for you (I'd suppose not)?
Doh. Silly me. It does pass the regression tests, all six of them. I
gues
Steve Crawford writes:
> I have a query that converts a string to an array with the
> string_to_array function. Sometimes the input is an empty string (not a
> null, but a string of zero-length). I had expected the result to be a
> one-element array with an empty string as the first and only el
Zdenek Kotala writes:
> I attached a fix. Only problem what I see there is getopt_long.h which
> contains
I'm more concerned about the "static int optreset", which is 100%
guaranteed to break things.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hacke
Bruce Momjian writes:
> Merlin Moncure wrote:
>>> I think we should just do PQinitOpenSSL(2 args) and be done with it.
>>
>> I was pushing for generic PQinit, but have come around and agree with
>> this point of view.
> OK, we are _go_ then.
Done. Let's hope this thread stays dead.
Andrew Chernow writes:
> I modified my previous patch to use a two-argument function solution.
Applied with minor changes (rename to PQinitOpenSSL per discussion,
some comment and docs improvements).
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hacker
2009/3/30 Tom Lane :
> Hitoshi Harada writes:
>> 2009/3/29 Tom Lane :
>>> ... What might be a bit saner is to remember the slot last passed to
>>> tuplestore_gettupleslot for each read pointer. The implication would be
>>> that we'd be assuming only one slot is used to fetch from any one read
>>>
Hi,
So I've been trying to get a plpython function that removes accented
letters, based on a Python snippet posted on another thread. The
function is simple enough:
create or replace function unaccent(text) returns text language plpythonu as $$
import unicodedata
s = unicodedata.normalize("NFKD"
Bruce Momjian writes:
> Andrew Dunstan wrote:
>> This is on the 8.3 code. Notice how this is formatted:
>>
>> hitrate = (float) BufferHitCount *100.0 / ReadBufferCount;
> The good news is that LocalBufferHitCount isn't in my list of typedefs
> from CVS HEAD, and probably not in 8.3 either. The
Andrew Dunstan wrote:
> >>> FWIW I was looking at this code for unrelated reasons and found a couple
> >>> of symbols that pgindent considers to be typedefs but it clearly are not
> >>> -- BufferHitCount and LocalBufferHitCount. It can be seen in
> >>> ShowBufferUsage().
> >>>
> >> Are you
On Mon, Mar 30, 2009 at 09:59:41PM +0200, Dimitri Fontaine wrote:
> Hi,
>
> Le 30 mars 09 à 16:52, Bruce Momjian a écrit :
>> I think the big question is whether the inconsistency (pattern implies
>> 'S') is worth accepting for greater usability.
>
>
> My answer is yes, please, definitely, go for i
Alvaro Herrera wrote:
> This is on the 8.3 code. Notice how this is formatted:
>
> hitrate = (float) BufferHitCount *100.0 / ReadBufferCount;
Hmm, I just noticed that this is mentioned as a "known bug" in pgindent.
Nevermind ...
--
Alvaro Herrerah
Alvaro Herrera wrote:
Bruce Momjian wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
Thanks. I will run tests when we are ready for pg_indent and we can
then make a decision.
FWIW I was looking at this code for unrelated reasons and found a couple
of symbols that
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> >
> > > Thanks. I will run tests when we are ready for pg_indent and we can
> > > then make a decision.
> >
> > FWIW I was looking at this code for unrelated reasons and found a couple
> > of symbols that pgindent considers
Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > Thanks. I will run tests when we are ready for pg_indent and we can
> > then make a decision.
>
> FWIW I was looking at this code for unrelated reasons and found a couple
> of symbols that pgindent considers to be typedefs but it clearly are not
Bruce Momjian wrote:
> Thanks. I will run tests when we are ready for pg_indent and we can
> then make a decision.
FWIW I was looking at this code for unrelated reasons and found a couple
of symbols that pgindent considers to be typedefs but it clearly are not
-- BufferHitCount and LocalBufferHi
Tom Lane píše v po 30. 03. 2009 v 14:04 -0400:
> Heikki Linnakangas writes:
> > Tom Lane wrote:
> >> Could we get away with just unconditionally calling
> >> bind_textdomain_codeset with *our* canonical spelling of the encoding
> >> name? If it works, great, and if it doesn't, you get English.
>
Hi,
Le 30 mars 09 à 16:52, Bruce Momjian a écrit :
I think the big question is whether the inconsistency (pattern implies
'S') is worth accepting for greater usability.
My answer is yes, please, definitely, go for it.
We don't need idiot-proof easy to remember semantics, we need useful
ones
Tom Lane píše v so 28. 03. 2009 v 14:36 -0400:
> Apparently the system version of getopt_long is broken on Solaris 11.
> My patience for this grows short.
It is not problem with getopt_long itself, but with symbol overriding.
getopt_long uses optind and so on from libc, but e.g. initdb takes
opt
Merlin Moncure wrote:
> On Mon, Mar 30, 2009 at 3:27 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> I guess that'd work but it might be overkill.
> >
> > The real bottom line is that *all* the proposals for generic init
> > functions are overkill. ?We have no evidence that we need one and
> > n
On Mon, Mar 30, 2009 at 3:27 PM, Tom Lane wrote:
> Robert Haas writes:
>> I guess that'd work but it might be overkill.
>
> The real bottom line is that *all* the proposals for generic init
> functions are overkill. We have no evidence that we need one and
> no certainty about what the requireme
On Mon, Mar 30, 2009 at 01:31:23PM -0400, Tom Lane wrote:
> David Fetter writes:
> > SELECT
> > i,
> > t,
> > RANK() OVER (
> > PARTITION BY i
> > ORDER BY random()
> > )
> > FROM foo;
> > ERROR: ORDER/GROUP BY expression not found in targetlist
>
> Fixed.
Thanks
Robert Haas writes:
> I guess that'd work but it might be overkill.
The real bottom line is that *all* the proposals for generic init
functions are overkill. We have no evidence that we need one and
no certainty about what the requirements for it would be if we did.
I think we should just do PQ
On Mon, Mar 30, 2009 at 2:59 PM, Andrew Chernow wrote:
> Robert Haas wrote:
>>
>> Or we might need a whole "char *" or "int" argument for some purpose
>> unrelated to SSL. Then we'll have a PQinit() function that pretends
>> to be a general-purpose initialization mechanism but really isn't.
>>
>
Robert Haas wrote:
Or we might need a whole "char *" or "int" argument for some purpose
unrelated to SSL. Then we'll have a PQinit() function that pretends
to be a general-purpose initialization mechanism but really isn't.
I proposed a PQinit() that included a void data pointer argument. The
Bruce Momjian wrote:
It seems having the init function return the bits it recognized would be
the logical return value.
That's what my first PQionitSecure patch did, actually it returned the
bits it didn't understand.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
S
j...@agliodbs.com (Josh Berkus) writes:
> This one is also really bad, but probably only Doc-patchable.
> However, can SQL/XML really be said to be core functionality if it
> only works in UTF-8?
> * BUG #4622: xpath only work in utf-8 server encoding
Well, much of the definition of XML assume
On Mon, Mar 30, 2009 at 2:31 PM, Bruce Momjian wrote:
> Tom Lane wrote:
>> Bruce Momjian writes:
>> > Tom Lane wrote:
>> >> And we get into the whole question of error handling, which is what
>> >> shot down that proposal last time.
>>
>> > Can you remind me of the details? I don't remember that
Tom Lane wrote:
What we need is an API equivalent to "iconv --list", but I'm not seeing
one :-(.
There's also "locale -m". Looking at the implementation of that, it just
lists what's in /usr/share/i18n/charmaps. Not too portable either..
Do we need to go so far as to try to run that progra
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> And we get into the whole question of error handling, which is what
> >> shot down that proposal last time.
>
> > Can you remind me of the details? I don't remember that issue.
> > Currently PQinitSSL() returns void, so I don't see
Tom Lane wrote:
I think we should stick with the simple two-argument function and not
+100
Generic PQinit concept was already punted several times. Using a bit
mask for initsecure or something was also tried and rejected. The well
is dry on this.
--
Andrew Chernow
eSilo, LLC
every b
Bruce Momjian writes:
> Tom Lane wrote:
>> And we get into the whole question of error handling, which is what
>> shot down that proposal last time.
> Can you remind me of the details? I don't remember that issue.
> Currently PQinitSSL() returns void, so I don't see an issue there.
The point is
Heikki Linnakangas writes:
> Tom Lane wrote:
>> Could we get away with just unconditionally calling
>> bind_textdomain_codeset with *our* canonical spelling of the encoding
>> name? If it works, great, and if it doesn't, you get English.
> Yeah, that's better than nothing.
A quick look at the o
Tom Lane wrote:
> Magnus Hagander writes:
> > Bruce Momjian wrote:
> >> Are we sure we don't want to add a more general libpq initialization
> >> control at this time?
> >>
> >> PQinitOptions(PG_NO_SSL_INIT | PG_NO_CRYPTO_INIT);
>
> > Could be an option but if we go down that path, it needs to b
Tom Lane wrote:
Heikki Linnakangas writes:
Tom Lane wrote:
Where does it get the default codeset from? Maybe we could constrain
that to match the database encoding, the way we do for LC_COLLATE/CTYPE?
LC_CTYPE. In 8.3 and up where we constrain that to match the database
encoding, we only h
Magnus Hagander writes:
> Bruce Momjian wrote:
>> Are we sure we don't want to add a more general libpq initialization
>> control at this time?
>>
>> PQinitOptions(PG_NO_SSL_INIT | PG_NO_CRYPTO_INIT);
> Could be an option but if we go down that path, it needs to be
> PG_NO_OPENSSL_SSL_INIT and P
Heikki Linnakangas writes:
> Tom Lane wrote:
>> Where does it get the default codeset from? Maybe we could constrain
>> that to match the database encoding, the way we do for LC_COLLATE/CTYPE?
> LC_CTYPE. In 8.3 and up where we constrain that to match the database
> encoding, we only have a pro
Bruce Momjian wrote:
> Magnus Hagander wrote:
>> On 30 mar 2009, at 17.24, Andrew Chernow wrote:
>>
>>> Tom Lane wrote:
BTW, unless someone objects I'd like to make the name of that
function
PQinitSecurity.
>>> Agreed. Although, both PQinitSecure and PQinitSecurity are very
>>>
Magnus Hagander wrote:
> On 30 mar 2009, at 17.24, Andrew Chernow wrote:
>
> > Tom Lane wrote:
> >> BTW, unless someone objects I'd like to make the name of that
> >> function
> >> PQinitSecurity.
> >
> > Agreed. Although, both PQinitSecure and PQinitSecurity are very
> > general names. "Se
Dave Page, 30.03.2009 14:28:
On Mon, Mar 30, 2009 at 1:06 PM, Thomas Kellerer wrote:
OK, thanks. I received very strange error messages last week when I accessed
that page. (Velocity Template not found and similar errors). But now it's
working.
Yeah, we had a big website update and that page
David Fetter writes:
> SELECT
> i,
> t,
> RANK() OVER (
> PARTITION BY i
> ORDER BY random()
> )
> FROM foo;
> ERROR: ORDER/GROUP BY expression not found in targetlist
Fixed.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsq
Tom Lane wrote:
Where does it get the default codeset from? Maybe we could constrain
that to match the database encoding, the way we do for LC_COLLATE/CTYPE?
LC_CTYPE. In 8.3 and up where we constrain that to match the database
encoding, we only have a problem with the C locale.
--
Heikki
Heikki Linnakangas writes:
> Tom Lane wrote:
>> Another idea is to try the values listed in our encoding_match_list[]
>> until bind_textdomain_codeset succeeds. The problem here is that the
>> GNU documentation is *exceedingly* vague about whether
>> bind_textdomain_codeset behaves sanely (ie thr
Tom Lane wrote:
Another idea is to try the values listed in our encoding_match_list[]
until bind_textdomain_codeset succeeds. The problem here is that the
GNU documentation is *exceedingly* vague about whether
bind_textdomain_codeset behaves sanely (ie throws a recognizable error)
when given a b
On Mon, Mar 30, 2009 at 11:56 AM, Magnus Hagander wrote:
> On 30 mar 2009, at 17.24, Andrew Chernow wrote:
>
>> Tom Lane wrote:
>>>
>>> BTW, unless someone objects I'd like to make the name of that function
>>> PQinitSecurity.
>>
>> Agreed. Although, both PQinitSecure and PQinitSecurity are very
On 30 mar 2009, at 17.24, Andrew Chernow wrote:
Tom Lane wrote:
BTW, unless someone objects I'd like to make the name of that
function
PQinitSecurity.
Agreed. Although, both PQinitSecure and PQinitSecurity are very
general names. "Security" can mean a lot of things. Maybe the name
s
I agree with Jaime that system triggers should execute independently of
user triggers.
In the particular case of partitioning, the system trigger should
execute after the user triggers. However, as the partitioning trigger is
a row level trigger, it is not clear what is going to happen with user
Le lundi 30 mars 2009 à 15:21:38, Sergey Burladyan a écrit :
> Peter Eisentraut writes:
> > I have now committed a more extensive pluralization, but your case is
> > included there.
> >
> > As for the ru.po file, please see http://babel.postgresql.org/.
>
> Great! I am translating 8.3 messages now
Tom Lane wrote:
BTW, unless someone objects I'd like to make the name of that function
PQinitSecurity.
Agreed. Although, both PQinitSecure and PQinitSecurity are very general
names. "Security" can mean a lot of things. Maybe the name should be
more particular, like PQinitOpenSSL. I th
Bruce Momjian wrote:
Merlin Moncure wrote:
On Mon, Mar 30, 2009 at 10:22 AM, Robert Haas wrote:
On Mon, Mar 30, 2009 at 9:36 AM, Andrew Chernow wrote:
Tom Lane wrote:
I personally would be happy with the two-argument function solution.
I modified my previous patch to use a two-argument fu
Merlin Moncure wrote:
> On Mon, Mar 30, 2009 at 10:22 AM, Robert Haas wrote:
> > On Mon, Mar 30, 2009 at 9:36 AM, Andrew Chernow wrote:
> >> Tom Lane wrote:
> >>>
> >>> I personally would be happy with the two-argument function solution.
> >>>
> >>
> >> I modified my previous patch to use a two-a
Merlin Moncure writes:
> On Mon, Mar 30, 2009 at 10:22 AM, Robert Haas wrote:
>> This looks OK to me, except I think we should modify the documentation
>> to PQinitSSL() to say that it you must not use both that function and
>> PQinitSecure(), and explain that if you need to control initializatio
Merlin Moncure wrote:
> On Mon, Mar 30, 2009 at 10:22 AM, Robert Haas wrote:
> > On Mon, Mar 30, 2009 at 9:36 AM, Andrew Chernow wrote:
> >> Tom Lane wrote:
> >>>
> >>> I personally would be happy with the two-argument function solution.
> >>>
> >>
> >> I modified my previous patch to use a two-a
On Mon, Mar 30, 2009 at 10:22 AM, Robert Haas wrote:
> On Mon, Mar 30, 2009 at 9:36 AM, Andrew Chernow wrote:
>> Tom Lane wrote:
>>>
>>> I personally would be happy with the two-argument function solution.
>>>
>>
>> I modified my previous patch to use a two-argument function solution.
>
> This lo
On Mon, Mar 30, 2009 at 6:51 AM, Kedar Potdar wrote:
>
>> As triggers are executed in order of their names, we've prefixed the
>> trigger names with "zz". This should work fine as long as no-one uses
>> trigger-name which starts with "zz".
>>
this seems a lot fragile... why system generated trig
Tom Lane wrote:
Bruce Momjian writes:
Tom Lane wrote:
It sounds like everyone has converged on agreeing that this way is okay
for 8.4? Object now or hold your peace ...
What are we doing with PQinitSSL()?
Nothing, except improving the documentation.
My patch didn't change the docs at
On Mon, Mar 30, 2009 at 10:52 AM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Mon, Mar 30, 2009 at 10:13 AM, Bruce Momjian wrote:
>> > Maybe the best we are going to do is to have any pattern supplied to \d*
>> > assume 'S' (include system objects). ?I actually have a patch that does
>> > tha
Tom Lane wrote:
> Robert Haas writes:
> > This looks OK to me, except I think we should modify the documentation
> > to PQinitSSL() to say that it you must not use both that function and
> > PQinitSecure(), and explain that if you need to control initialization
> > of libcrypto and libssl, you sho
Robert Haas wrote:
> On Mon, Mar 30, 2009 at 10:13 AM, Bruce Momjian wrote:
> > Maybe the best we are going to do is to have any pattern supplied to \d*
> > assume 'S' (include system objects). ?I actually have a patch that does
> > that, attached. (It is from January so might need adjustment.)
>
Marko Kreen writes:
> Well, that was also my theory. But my point is that such lockless code
> should be written in more stricter way so it's effects can be clearly
> deduced.
We don't really care that much, for what CountActiveBackends is used for.
> Or at least such roundabout effects should
--On Freitag, März 27, 2009 14:59:23 -0400 Tom Lane
wrote:
Should we consider doing something about that, or is it okay as-is?
I'd say yes, but i don't understand why xmlelement() doesn't call
map_sql_value_to_xml_value() already instead of calling the output function
directly?
--
Thank
On Mon, Mar 30, 2009 at 10:29 AM, Tom Lane wrote:
> Robert Haas writes:
>> That still has the problem that "\df a*" is horribly inconsistent with
>> "\df". It might be reasonable to assume that if a name without
>> wildcards is given to any \d command, it should display whatever
>> object it fin
Maybe the best we are going to do is to have any pattern supplied to \d*
assume 'S' (include system objects). I actually have a patch that does
that, attached. (It is from January so might need adjustment.)
---
Robert Haas
Tom Lane wrote:
> Andrew Chernow writes:
> > I modified my previous patch to use a two-argument function solution.
>
> It sounds like everyone has converged on agreeing that this way is okay
> for 8.4? Object now or hold your peace ...
What are we doing with PQinitSSL()?
--
Bruce Momjian
On 3/30/09, Tom Lane wrote:
> Heikki Linnakangas writes:
>
> > Marko Kreen wrote:
> >> Without reset in ProcArrayRemove we may use some ancient pointer that
> >> may point to garbage? I don't think it's good coding style to allow
> >> that to happen.
>
> > Well, that can happen anyway. Count
On Mon, Mar 30, 2009 at 10:13 AM, Bruce Momjian wrote:
> Maybe the best we are going to do is to have any pattern supplied to \d*
> assume 'S' (include system objects). I actually have a patch that does
> that, attached. (It is from January so might need adjustment.)
That still has the problem t
Robert Haas writes:
> This looks OK to me, except I think we should modify the documentation
> to PQinitSSL() to say that it you must not use both that function and
> PQinitSecure(), and explain that if you need to control initialization
> of libcrypto and libssl, you should use that function inst
On Mon, Mar 30, 2009 at 9:36 AM, Andrew Chernow wrote:
> Tom Lane wrote:
>>
>> I personally would be happy with the two-argument function solution.
>>
>
> I modified my previous patch to use a two-argument function solution.
This looks OK to me, except I think we should modify the documentation
t
Robert Haas writes:
> That still has the problem that "\df a*" is horribly inconsistent with
> "\df". It might be reasonable to assume that if a name without
> wildcards is given to any \d command, it should display whatever
> object it finds, user or system - but I can't see doing it for any
> w
On Sun, Mar 29, 2009 at 1:32 PM, Tom Lane wrote:
> Now I *have* a user function named sin(), it's not getting called
> (which might surprise me if I didn't know there was a conflicting
> system function) and \df doesn't show me either one.
>
> I actually was expecting the above example to show me
Bruce Momjian writes:
> Tom Lane wrote:
>> It sounds like everyone has converged on agreeing that this way is okay
>> for 8.4? Object now or hold your peace ...
> What are we doing with PQinitSSL()?
Nothing, except improving the documentation.
regards, tom lane
--
Sen
Heikki Linnakangas writes:
> Marko Kreen wrote:
>> Without reset in ProcArrayRemove we may use some ancient pointer that
>> may point to garbage? I don't think it's good coding style to allow
>> that to happen.
> Well, that can happen anyway. CountActiveBackends() could fetch the
> pointer an
On 3/30/09, Heikki Linnakangas wrote:
> Marko Kreen wrote:
>
> > On 3/30/09, Heikki Linnakangas
> wrote:
> >
> > > Agreed. And more importantly, it puts the onus of getting it right into
> > > CountActiveBackends, which is the one who's breaking the rules. We don't
> > > necessarily need to clea
Marko Kreen wrote:
On 3/30/09, Heikki Linnakangas wrote:
Agreed. And more importantly, it puts the onus of getting it right into
CountActiveBackends, which is the one who's breaking the rules. We don't
necessarily need to clear the pointer in ProcArrayRemove either, the count
doesn't need to b
Andrew Chernow writes:
> I modified my previous patch to use a two-argument function solution.
It sounds like everyone has converged on agreeing that this way is okay
for 8.4? Object now or hold your peace ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (p
On 3/30/09, Heikki Linnakangas wrote:
> Marko Kreen wrote:
>
> > 1. Add memory barrier to ProcArrayAdd/ProcArrayRemove between pointer
> >and count update. This guarantees that partial slots will not be seen.
> >
> > 2. Always clear the pointer in ProcArrayRemove and check for NULL
> >i
Tom Lane wrote:
I personally would be happy with the two-argument function solution.
I modified my previous patch to use a two-argument function solution.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
Index: doc/src/sgml/libpq.sgml
==
Heikki Linnakangas writes:
> In CVS HEAD, we call bind_textdomain_codeset() in SetDatabaseEncoding()
> which fixes that, but we only do it on Windows. In earlier versions we
> called it on all platforms, but only for UTF-8. It seems that we should
> call bind_textdomain_codeset on all platforms
Peter Eisentraut writes:
> I have now committed a more extensive pluralization, but your case is
> included
> there.
>
> As for the ru.po file, please see http://babel.postgresql.org/.
Great! I am translating 8.3 messages now. After this, i will go to HEAD.
ps:
By the way, when 8.4 will be r
On Thu, Mar 26, 2009 at 4:54 AM, Guillaume Smet wrote:
> Hi Simon.
>
> On Thu, Mar 26, 2009 at 11:50 AM, Simon Riggs
> wrote:
> > Earlier, we discussed having a single trigger file that contains an
> > option rather than two distinct trigger files. That design is better
> > because it allows the
Marko Kreen wrote:
1. Add memory barrier to ProcArrayAdd/ProcArrayRemove between pointer
and count update. This guarantees that partial slots will not be seen.
2. Always clear the pointer in ProcArrayRemove and check for NULL
in all "lockless" access points. This guarantees that part
latin1db=# SELECT version();
version
---
PostgreSQL 8.3.7 on i686-pc-linux-gnu, compiled by GCC gcc (Debian
4.3.3-5) 4.3.3
(1 row)
latin1db=# SELECT name, setting FROM pg_se
Hello,
Our implementation of variadic parameters are not complete. The
support of "any" type is incomplete. Modificator VARIADIC for funccall
parameters needs transformation from ArrayExpr to standard parameters
list.
==current behave==
postgres=# select variadic_demo2(10,'Petr',20,20,30);
NOTICE
On Sun, Mar 29, 2009 at 1:56 PM, Bruce Momjian wrote:
> I think this is where we got stuck because extending libpq with a new
> function is a larger API change, and not having a clear plan of what
> initialization stuff we might need in the future, it seems unwise, and
> also perhaps overkill.
ri
On Mon, Mar 30, 2009 at 1:06 PM, Thomas Kellerer wrote:
>
> OK, thanks. I received very strange error messages last week when I accessed
> that page. (Velocity Template not found and similar errors). But now it's
> working.
Yeah, we had a big website update and that page got messed up along
the w
Hi Emmanuel,
Thanks for your time. This is a WIP patch and we will integrate your
suggestions/comments as appropriate.
Regards,
--
Kedar.
On Fri, Mar 27, 2009 at 3:38 AM, Emmanuel Cecchet wrote:
> Hi Kedar,
>
> First of all, congratulations for the excellent work.
> I have some comments and que
We got a crash in our test-server, which has huge number of backends
running:
(gdb) bt
#0 CountActiveBackends () at procarray.c:1094
#1 0x00475f45 in RecordTransactionCommit () at xact.c:945
#2 0x0047601c in CommitTransaction () at xact.c:1675
#3 0x00476247 in CommitTra
Tom Lane píše v so 28. 03. 2009 v 14:36 -0400:
> I wrote:
> > After reviewing this thread and the one that led up to the 8.3 behavior,
> > it seems clear that we failed to draw a distinction between getopt and
> > getopt_long when we should have. We don't like Solaris' getopt but
> > there seems
On Mon, Mar 30, 2009 at 7:56 AM, Thomas Kellerer wrote:
> Devrim GÜNDÜZ, 28.03.2009 10:02:
>>
>> As we are moving very close to 8.4 beta, please join us for testing 8.4
>> release.
>>
>> I just released new RPM sets, which is based on Mar 27 CVS snapshot.
>> Please note that these packages are **n
(Sorry for delay..)
Guillaume Smet wrote:
Being able to detect which application is running which query on the
very same database with the very same user seems like something not so
obvious and the use case seems to be pretty narrow. And IMHO, even if
we suppose you can make the difference betwe
99 matches
Mail list logo
