On Tue, Apr 03, 2007 at 01:06:38PM -0400, Tom Lane wrote:
> I think it's probably defensible for non-Unicode encodings. To do
> otherwise would require (a) figuring out what the equivalent concept to
> "code point" is for each encoding, and (b) having a separate code path
> for each encoding to pe
Klint Gore <[EMAIL PROTECTED]> writes:
> Is there any way to create operators to point like to ilike? There
> doesn't seem to be a like or ilike in pg_operator (not in 7.4 anyway).
Actually it's the other way 'round: if you look into gram.y you'll see
that LIKE is expanded as the operator ~~ and
Josh,
On 3/31/07 11:01 AM, "Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
> The PostgreSQL project should not give any credence to these
> announcements and should avoid all patent issues possible.
I think that's appropriate - the structure of the OIN looks like it's:
1) focused on Linux
2) design
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Note to hackers: would it make sense to use write() instead of
>> fprintf() in send_message_to_server_log to avoid any possibility
>> of stdio deciding to fragment the message? Possibly there'd be
>> some marginal efficiency gain too.
On Tue, 2007-04-03 at 15:02 -0400, Tom Lane wrote:
> Tim Goodaire <[EMAIL PROTECTED]> writes:
> > While going through some log files, we noticed that some of the log entries
> > are "garbled". For example:
>
> > 2007-03-27 01:19:44.139 UTC [1761474] oxrsa aepp xx.xx.xx.xx LOG:
> > duratio2007-03
Tom Lane wrote:
Note to hackers: would it make sense to use write() instead of
fprintf() in send_message_to_server_log to avoid any possibility
of stdio deciding to fragment the message? Possibly there'd be
some marginal efficiency gain too.
What about in write_syslogger_file_binary()? Sinc
Tim Goodaire <[EMAIL PROTECTED]> writes:
> While going through some log files, we noticed that some of the log entries
> are "garbled". For example:
> 2007-03-27 01:19:44.139 UTC [1761474] oxrsa aepp xx.xx.xx.xx LOG:
> duratio2007-03-n: 3751.27 01:19801 ms :44.139 statemenUTC [421940]
> oxrt: E
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> On 4/3/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>> If the invalidation were something that *had* to be accounted for,
>> such as a dropped index, then there should be adequate locking for it;
>> plancache is not introducing any new bug that wasn't there
On 4/3/07, Tom Lane <[EMAIL PROTECTED]> wrote:
I'm not particularly worried about missing a potential improvement
in the plan during the first command after a change is committed.
Me too. Just noticed it, so brought it up.
If the invalidation were something that *had* to be accounted for
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> I traced it a bit and it seems that the invalidation messages
> are not accepted in session 2 because the locks are already held
> on the relation.
Right, because of this coding in LockRelationOid():
/*
* Now that we have the lock, check for
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
We'll also need to store the database id along with the event name and
message, since pg_listener is per db rather than per cluster.
Well, that's an artifact of the historical implementation ... does
anyone want to argue that LISTEN sh
Albe Laurenz wrote:
What I suggest (and what Oracle implements, and isn't CHR() and ASCII()
partly for Oracle compatibility?) is that CHR() and ASCII()
convert between a character (in database encoding) and
that database encoding in numeric form.
Looking at Oracle documentation, it appears that
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> We'll also need to store the database id along with the event name and
> message, since pg_listener is per db rather than per cluster.
Well, that's an artifact of the historical implementation ... does
anyone want to argue that LISTEN should be cluster
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The start script does not typically have the intelligence to get this
>> right, particularly not the is-shmem-still-in-use part. If you check
>> the archives you will find many of us on record telling people who think
>> they should re
On Tue, 2007-04-03 at 10:01 +0100, Simon Riggs wrote:
> On Mon, 2007-04-02 at 16:14 -0700, Jeff Davis wrote:
>
> > The results are very positive and quite conclusive.
>
> Can we show some summary results?
I should be able to make some graphs today.
> I'm happy that the scans stay together all t
Tom Lane wrote:
Hannu Krosing <[EMAIL PROTECTED]> writes:
Ühel kenal päeval, T, 2007-03-27 kell 07:11, kirjutas Andrew Dunstan:
Er, what listen table?
At least the list of which backends listen to which events should be
also in shared mem.
No, the intent is specifi
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> FWIW, is the attached patch about what you had in mind? (It probably only
> covers "normal" types at the moment.)
Hm, I hadn't realized that it would take as little work as that ...
I have an itchy feeling that you missed something but I'm not sure
Mark Dilger <[EMAIL PROTECTED]> writes:
> Martijn van Oosterhout wrote:
>> Just about every multibyte encoding other than Unicode has the problem
>> of not distinguishing between the code point and the encoding of it.
> Thanks for the feedback. Would you say that the way I implemented things in
Peter,
Which precise implicit casts are we breaking? Can we provide an exact list in
the release notes?
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
Martijn van Oosterhout wrote:
On Tue, Apr 03, 2007 at 11:43:21AM +0200, Albe Laurenz wrote:
IMHO this is the only good and intuitive way for CHR() and ASCII().
Hardly. The comment earlier about mbtowc was much closer to the mark.
And wide characters are defined as Unicode points.
Basically, C
Tom Lane wrote:
Zdenek Kotala <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Just to distinguish postmasters from standalone backends in the error
messages. I think that's still useful.
I'm not sure what you mean. It is used only in CreatePidFile function
and I think that if directory is locke
On Mon, 2007-04-02 at 21:38 -0700, Luke Lonergan wrote:
> Jeff,
>
> Your conclusions sound great - can you perhaps put the timings in a column
> in your table so we can confirm them?
>
I just threw the logs up, which contain the timings involved. I will try
to make graphs out of them, but the da
Am Montag, 2. April 2007 18:41 schrieb Tom Lane:
> >> The scheme that was in the back of my mind was to do this at the same
> >> time as providing a general facility for casting *every* type to and
> >> from text, by means of their I/O functions if no specialized cast is
> >> provided in pg_cast.
Andrew wrote:
>> According to RFC 2279, the Euro,
>> Unicode code point 0x20AC = 0010 1010 1100,
>> will be encoded to 1110 0010 1000 0010 1010 1100 = 0xE282AC.
>>
>> IMHO this is the only good and intuitive way for CHR() and ASCII().
>
> It is beyond ludicrous for functions like chr() or asc
Am Dienstag, 3. April 2007 17:17 schrieb Bruce Momjian:
> I assumed the issue was that there might not be explicit casts for every
> case were were now disallowing.
My proposal is to "downgrade" some casts from implicit to assignment. Tom's
proposal is to add more casts at the level of explicit,
Great, patch applied and TODO item removed.
---
Marko Kreen wrote:
> On 4/3/07, Marko Kreen <[EMAIL PROTECTED]> wrote:
> > On 4/3/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > > Great. Care to take on the Python boolean
Hi,
The following things are TODOs:
iv) Auto generate rules using the checks mentioned for the partitions, to
handle INSERTs/DELETEs/UPDATEs to navigate them to the appropriate child.
Note that checks specified directly on the master table will get inherited
automatically.
Am planning to do
While going through some log files, we noticed that some of the log entries
are "garbled". For example:
2007-03-27 01:19:44.139 UTC [1761474] oxrsa aepp xx.xx.xx.xx LOG:
duratio2007-03-n: 3751.27 01:19801 ms :44.139 statemenUTC [421940]
oxrt: EXECUsor
g aTE [P0.136.10REPARE: 8 LOG: select
d
On 4/3/07, Marko Kreen <[EMAIL PROTECTED]> wrote:
On 4/3/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> Great. Care to take on the Python boolean patch?
>
> o Allow PL/PythonU to return boolean rather than 1/0
I think this should be also solved with backwards-compat ifdef.
Tested with p
Peter Eisentraut wrote:
> Am Montag, 2. April 2007 18:41 schrieb Tom Lane:
> > Certainly they'd all be explicit-only. ?From a technical perspective
> > there's no need to do the two things at the same time; I'm just opining
> > that we could sell it easier if we did them together. ?If we just do
>
Am Montag, 2. April 2007 18:41 schrieb Tom Lane:
> Certainly they'd all be explicit-only. From a technical perspective
> there's no need to do the two things at the same time; I'm just opining
> that we could sell it easier if we did them together. If we just do
> this part, what users will see i
On Tue, Apr 03, 2007 at 11:43:21AM +0200, Albe Laurenz wrote:
> IMHO this is the only good and intuitive way for CHR() and ASCII().
Hardly. The comment earlier about mbtowc was much closer to the mark.
And wide characters are defined as Unicode points.
Basically, CHR() takes a unicode point and r
Tom,
On 4/3/07 7:15 AM, "Tom Lane" <[EMAIL PROTECTED]> wrote:
> BTW, it strikes me that a GUC variable is quite the wrong way to go
> about this. The right way is a table storage parameter, a la FILLFACTOR,
> so that it can be set on a per-table basis. That would also give us a
> chance to fix
Tom Lane wrote:
> David Fetter <[EMAIL PROTECTED]> writes:
> > On Mon, Apr 02, 2007 at 10:01:44PM -0400, Alvaro Herrera wrote:
> >> So, hum, what happened to the idea of creating the array types only
> >> on demand?
>
> > Scotched, as far as I could tell,
>
> More like "you submitted a patch that
Chris Browne <[EMAIL PROTECTED]> writes:
> Here's a "drafty" patch that *tries* to do this using a GUC variable;
> it passes some interactive testing.
BTW, it strikes me that a GUC variable is quite the wrong way to go
about this. The right way is a table storage parameter, a la FILLFACTOR,
so th
I noticed that the plan invalidation is not immediately effective.
Not sure whether it's worth fixing or has any other side-effects,
but thought would just post it.
I was testing the following scenario:
session1session2
CREATE TABLE test
(int a, int b)
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Nor will that work for prepared xacts --- you don't want to wait for the
eventual commit, only for PREPARE TRANSACTION to exit its critical
section.
PREPARE TRANSACTION wouldn't set the flag in MyProc; there's no c
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Nor will that work for prepared xacts --- you don't want to wait for the
>> eventual commit, only for PREPARE TRANSACTION to exit its critical
>> section.
> PREPARE TRANSACTION wouldn't set the flag in MyProc; there's no clog
> c
On 4/3/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
Great. Care to take on the Python boolean patch?
o Allow PL/PythonU to return boolean rather than 1/0
http://archives.postgresql.org/pgsql-patches/2007-01/msg00596.php
It requires only a few lines of code, but some testing, wh
On 2007-04-03, "Albe Laurenz" <[EMAIL PROTECTED]> wrote:
> According to RFC 2279, the Euro,
> Unicode code point 0x20AC = 0010 1010 1100,
> will be encoded to 1110 0010 1000 0010 1010 1100 = 0xE282AC.
>
> IMHO this is the only good and intuitive way for CHR() and ASCII().
It is beyond ludicro
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Ko
Patch applied. Thanks.
---
Marko Kreen wrote:
> On 4/3/07, Marko Kreen <[EMAIL PROTECTED]> wrote:
> > On 4/3/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > > Where are we on Python 2.5?
> >
> > I'll look into it.
>
> Fo
Great. Care to take on the Python boolean patch?
o Allow PL/PythonU to return boolean rather than 1/0
http://archives.postgresql.org/pgsql-patches/2007-01/msg00596.php
It requires only a few lines of code, but some testing, which you seem
to have available.
-
On Tue, Apr 03, 2007 at 02:30:07AM -0400, Tom Lane wrote:
> David Fetter <[EMAIL PROTECTED]> writes:
> > On Mon, Apr 02, 2007 at 10:01:44PM -0400, Alvaro Herrera wrote:
> >> So, hum, what happened to the idea of creating the array types
> >> only on demand?
>
> > Scotched, as far as I could tell,
Marko Kreen escribió:
> On 4/3/07, Marko Kreen <[EMAIL PROTECTED]> wrote:
> >On 4/3/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> >> Where are we on Python 2.5?
> >
> >I'll look into it.
>
> Following patch converts plpython.c to use Python 2.5 types,
> with compat ifdef for older version. This
From: "Dave Page" <[EMAIL PROTECTED]>
Magnus Hagander wrote:
On Tue, Apr 03, 2007 at 06:16:26PM +0900, Hiroshi Saito wrote:
Slony-I is still used...Ahh, I have not confirmed it yet.
Slony uses it, yes. It would probably be worthwhile to fix that one as
well, but I haven't looked at how much
Magnus Hagander wrote:
On Tue, Apr 03, 2007 at 06:16:26PM +0900, Hiroshi Saito wrote:
Slony-I is still used...Ahh, I have not confirmed it yet.
Slony uses it, yes. It would probably be worthwhile to fix that one as
well, but I haven't looked at how much work that would be.
And to port the bu
On Tue, Apr 03, 2007 at 06:16:26PM +0900, Hiroshi Saito wrote:
> Hi.
>
> >>Am I misunderstanding it?
> >
> >That is intended. With the changes that was put in to ecpg, pthreads is no
> >longer required. We use the native threading on Windows instead.
> >
> >Also, enable_thread_safety is now the d
what can't be purchased and silenced, should be killed with rain of law suits.
Microsoft does it, novell does it, sco does it, and oracle too.
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql
Bruce Momjian wrote:
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
Thank you very much for including. Attached is an update of the patch
according to Simon Riggs's comment about GUC name.
Regards;
--
Koichi
On 4/3/07, Marko Kreen <[EMAIL PROTECTED]> wrote:
On 4/3/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> Where are we on Python 2.5?
I'll look into it.
Following patch converts plpython.c to use Python 2.5 types,
with compat ifdef for older version. This is recommended
method by PEP 353 to fix
Here's third revision of WAL archival optimization patch. GUC
parameter name was changed to wal_add_optimization_info.
Regards;
--
Koichi Suzuki
20070403_pg_lesslog.tar.gz
Description: application/gzip
---(end of broadcast)---
TIP 1: if postin
Mark Dilger wrote:
>>> In particular, in UTF8 land I'd have expected the argument of chr()
>>> to be interpreted as a Unicode code point, not as actual UTF8 bytes
>>> with a randomly-chosen endianness.
>>>
>>> Not sure what to do in other multibyte encodings.
>>
>> "Not sure what to do in other mu
Hi.
Am I misunderstanding it?
That is intended. With the changes that was put in to ecpg, pthreads is no
longer required. We use the native threading on Windows instead.
Also, enable_thread_safety is now the default for windows :-)
Ooops, Isn't pthreadGC2 necessary?
Slony-I is still used.
On Tue, Apr 03, 2007 at 06:06:16PM +0900, Hiroshi Saito wrote:
> Hi Magnus.
>
> configure was changed the cvs head.
> Is this what you intended it?_?
>
> I think necessary to recover it.
>
> *** configure.orig Tue Apr 3 17:51:06 2007
> --- configure Tue Apr 3 17:52:21 2007
> ***
Hi Magnus.
configure was changed the cvs head.
Is this what you intended it?_?
I think necessary to recover it.
*** configure.orig Tue Apr 3 17:51:06 2007
--- configure Tue Apr 3 17:52:21 2007
***
*** 16732,16739
# For each platform, we need to know about any special
On Mon, 2007-04-02 at 16:14 -0700, Jeff Davis wrote:
> The results are very positive and quite conclusive.
Can we show some summary results?
I'm happy that the scans stay together all the way around, even handling
the max-> 0 blockid transition well. So definite winner for me.
> However, the "s
On 4/3/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
Where are we on Python 2.5?
I'll look into it.
--
marko
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PR
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
What sort of "wait for finish" mechanism do you have in mind?
I was thinking of XactLockTableWait.
Ugh. I don't think the bgwriter can participate in heavyweight-lockmgr
operations, or should become able to.
> > ... should we revel
> > in configurability, and allow CREATE TABLE/ALTER TABLE behavior to
> > vary depending on the current threshold setting? We'd have to fix
the
> > toaster routines to not try to push stuff out-of-line when there is
no
> > out-of-line to push to ... but I think we prob
On Mon, 2007-04-02 at 19:09 -0400, Bruce Momjian wrote:
> Where is this patch?
see Hackers thread: "Minor changes to Recovery related code", Mar 30
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)-
Pavel Stehule wrote:
> it's problem. You cannot do it now. One year ago I sent patch
>
> http://archives.postgresql.org/pgsql-patches/2006-03/msg00196.php
The only comments to that were that no one knew what it was good for.
But now we know, so I think we should add your patch.
Tom Lane did it
62 matches
Mail list logo
