On Aug 19, 2010, at 2:35 PM, Tom Lane wrote:
> Steven Schlansker writes:
>> I'm having a rather annoying problem - a particular string is causing the
>> Postgres COPY functionality to lose a byte, causing data corruption in
>> backups and transferred data.
>
> I was able to reproduce this on m
On Aug 19, 2010, at 3:24 PM, Tom Lane wrote:
> Steven Schlansker writes:
>>
>> I'm not at all experienced with character encodings so I could
>> be totally off base, but isn't it wrong to ever call isspace(0x85),
>> whatever the result may be, given that the actual character is 0xCF85?
>> (U+03
Robert Haas writes:
> So I propose moving the TablespaceCreateDbspace() call to mdcreate(),
> removing the redundant check from smgrcreate(), and deleting that
> portion of the comment which says this is in the wrong place.
While I don't care for having smgr.c call tablespace.c, moving the call t
(2010/08/20 11:45), Robert Haas wrote:
> 2010/8/19 KaiGai Kohei:
>> I also plan to add a security hook on authorization time.
>> It shall allow external security providers to set up credential of
>> the authenticated clients.
>>
>> Please note that it is not intended to control authentication proce
2010/8/19 KaiGai Kohei :
> I also plan to add a security hook on authorization time.
> It shall allow external security providers to set up credential of
> the authenticated clients.
>
> Please note that it is not intended to control authentication process.
> It is typically checked based on a pair
smgrcreate() currently contains a call to TablespaceCreateDbspace().
As the comment says, this is a rather silly place to put it. The
silliest thing about it, IMHO, is that it forces the following check
to be done in both smgrcreate() and mdcreate():
if (isRedo && reln->md_fd[forknum] != NU
I also plan to add a security hook on authorization time.
It shall allow external security providers to set up credential of
the authenticated clients.
Please note that it is not intended to control authentication process.
It is typically checked based on a pair of username and password.
What I wa
On Thu, Aug 19, 2010 at 06:03:57PM -0400, Robert Haas wrote:
> On Thu, Aug 19, 2010 at 5:53 PM, David Fetter wrote:
> > On Thu, Aug 19, 2010 at 05:40:46PM -0400, Tom Lane wrote:
> >> "Kevin Grittner" writes:
> >> > Robert Haas wrote:
> >> >> I suppose there could also be a bit of an ambiguity if
> We generally assume that in server-safe encodings, the ctype.h functions
> will behave sanely on any single-byte value.
I think this "wisedom" is only true for C locale. I'm not surprised
all that it does not work with non C locales.
>From array_funcs.c:
while (isspace((unsign
Fujii Masao writes:
> The explanation of trace_recovery_messages in the document
> is inconsistent with the definition of it in guc.c.
I've applied a patch for this.
I was tempted to propose that we just rip out trace_recovery_messages
altogether, but I suppose Simon would object.
I don't know how to edit documents exactly before.
Thanks.
On Thu, 19 Aug 2010 08:48:53 -0700
David Fetter wrote:
> On Thu, Aug 19, 2010 at 10:24:54PM +0800, Quan Zongliang wrote:
> > documents attached. html and man-page
>
> Thanks!
>
> For future reference, the way to patch docs is by patch
Because Windows's CreateService has serial start-type:
SERVICE_AUTO_START
SERVICE_BOOT_START
SERVICE_DEMAND_START
SERVICE_DISABLED
SERVICE_SYSTEM_START
Although all of them are not useful for pg service.
I think it is better to use enum.
On Thu, 19 Aug 2010 16:48:53 -0400
Alvaro Herrera wrote:
Kevin,
This one is for you:
Two sessions, in transaction:
Process A Process B
update session where id = X;
update order where orderid = 5;
update order where orderid = 5;
update order where orderid = 5;
... deadlock error.
It seems
Steven Schlansker writes:
> On Aug 19, 2010, at 2:35 PM, Tom Lane wrote:
>> I was able to reproduce this on my own Mac. Some tracing shows that the
>> problem is that isspace(0x85) returns true when in locale en_US.utf-8.
>> This causes array_in to drop the final byte of the array element string,
On Thu, Aug 19, 2010 at 5:53 PM, David Fetter wrote:
> On Thu, Aug 19, 2010 at 05:40:46PM -0400, Tom Lane wrote:
>> "Kevin Grittner" writes:
>> > Robert Haas wrote:
>> >> I suppose there could also be a bit of an ambiguity if you're working
>> >> with a type like int4 where the values are discre
On Thu, Aug 19, 2010 at 05:40:46PM -0400, Tom Lane wrote:
> "Kevin Grittner" writes:
> > Robert Haas wrote:
> >> I suppose there could also be a bit of an ambiguity if you're working
> >> with a type like int4 where the values are discrete steps. Like, what
> >> do you do with {1, 2}?
>
> Hmm,
"Kevin Grittner" writes:
> Robert Haas wrote:
>> I suppose there could also be a bit of an ambiguity if you're working
>> with a type like int4 where the values are discrete steps. Like, what
>> do you do with {1, 2}?
Hmm, good point.
> The same thing you do with the avg function?
avg's appr
On Thu, 2010-08-19 at 23:30 +0200, Magnus Hagander wrote:
> It might well be, and the cost is low. But if you're talking about
> gitweb links or so, they'll still be invalid, because it would have to
> be renamed to "postgresql-old" or something like that...
Sure, that's fine.
It would just be ni
Steven Schlansker writes:
> I'm having a rather annoying problem - a particular string is causing the
> Postgres COPY functionality to lose a byte, causing data corruption in
> backups and transferred data.
I was able to reproduce this on my own Mac. Some tracing shows that the
problem is that
On Thu, Aug 19, 2010 at 5:29 PM, Jeff Davis wrote:
> The new git repository will have different SHA1s for all of the commits,
> so any old SHA1s will be useless without the old repository.
>
> Hopefully nobody used links to specific commits (or SHA1s) pointing to
> the old git repository for anyth
On Thu, Aug 19, 2010 at 23:29, Jeff Davis wrote:
> The new git repository will have different SHA1s for all of the commits,
> so any old SHA1s will be useless without the old repository.
>
> Hopefully nobody used links to specific commits (or SHA1s) pointing to
> the old git repository for anythin
The new git repository will have different SHA1s for all of the commits,
so any old SHA1s will be useless without the old repository.
Hopefully nobody used links to specific commits (or SHA1s) pointing to
the old git repository for anything important. But I found myself doing
so occasionally for u
From: Tom Lane mailto:t...@sss.pgh.pa.us>>
Date: August 19, 2010 10:25:36 AM PDT
To: David Fetter mailto:da...@fetter.org>>
Cc: Kevin Grittner
mailto:kevin.gritt...@wicourts.gov>>, Robert Haas
mailto:robertmh...@gmail.com>>, Pavel Stehule
mailto:pavel.steh...@gmail.com>>, Greg Stark
mailto:gsst
Robert Haas wrote:
> While examining gram.y today I happened to notice an oversight in
the
> grammar rules for creating typed tables: the fourth CREATE TABLE
> production ignores $2. Which I think means (although of course I
> didn't test it) that if you do something like "CREATE TEMP TABLE IF
On Thu, Aug 19, 2010 at 04:48:53PM -0400, Alvaro Herrera wrote:
> Excerpts from David Fetter's message of jue ago 19 16:40:18 -0400 2010:
> > On Thu, Aug 19, 2010 at 03:47:43PM -0400, Alvaro Herrera wrote:
> > > Excerpts from David Fetter's message of jue ago 19 11:48:53 -0400 2010:
> > >
> > > >
While examining gram.y today I happened to notice an oversight in the
grammar rules for creating typed tables: the fourth CREATE TABLE
production ignores $2. Which I think means (although of course I
didn't test it) that if you do something like "CREATE TEMP TABLE IF
NOT EXISTS foo OF bar", the TE
Excerpts from David Fetter's message of jue ago 19 16:40:18 -0400 2010:
> On Thu, Aug 19, 2010 at 03:47:43PM -0400, Alvaro Herrera wrote:
> > Excerpts from David Fetter's message of jue ago 19 11:48:53 -0400 2010:
> >
> > > +
> > > + -S > > class="parameter">
> >
> > You omitted the star
On Thu, Aug 19, 2010 at 03:47:43PM -0400, Alvaro Herrera wrote:
> Excerpts from David Fetter's message of jue ago 19 11:48:53 -0400 2010:
>
> > +
> > + -S > class="parameter">
>
> You omitted the start-type inside the tag. Also, the "a"
> and "d" values seem to be accepted but not docu
Robert Haas wrote:
> I suppose there could also be a bit of an ambiguity if you're
working
> with a type like int4 where the values are discrete steps. Like,
what
> do you do with {1, 2}?
The same thing you do with the avg function?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hac
On Thu, Aug 19, 2010 at 4:21 PM, Tom Lane wrote:
> Robert Haas writes:
>> You've made this assertion at least three times now, but I confess
>> that I've only ever learned one way to compute a median; and quick
>> Google searches for "median", "kinds of median", and few other
>> variants failed t
Robert Haas writes:
> You've made this assertion at least three times now, but I confess
> that I've only ever learned one way to compute a median; and quick
> Google searches for "median", "kinds of median", and few other
> variants failed to turn up anything obvious either.
There are different
On Thu, Aug 19, 2010 at 9:46 AM, David Fetter wrote:
> As to median, please make sure you say in detail which median you're
> using and name it so, as there is no single, authoritative median.
You've made this assertion at least three times now, but I confess
that I've only ever learned one way t
Excerpts from David Fetter's message of jue ago 19 11:48:53 -0400 2010:
> +
> + -S class="parameter">
You omitted the start-type inside the tag. Also, the "a"
and "d" values seem to be accepted but not documented.
--
Álvaro Herrera
The PostgreSQL Company - Command Prompt, Inc.
Postg
Robert Haas writes:
> Any other kibitzing before I commit this?
Sure ...
+ * If the object is a relation or a child object of a relation (e.g. an
+ * attribute or contraint, *relp will set to point to that relation). This
Parenthesis in the wrong place here, grammar and spelling not much bet
David Fetter writes:
> On Thu, Aug 19, 2010 at 01:25:36PM -0400, Tom Lane wrote:
>> A name like "arithmetic_median" seems much less likely to get
>> blindsided by future standardization.
> Yep.
OTOH, if Pavel's right that Oracle already has an aggregate named
median(), it seems quite unlikely th
Pavel Stehule wrote:
> I looked there and Oracle11g use "median" in common sense.
As does Sybase IQ. FWIW, Excel spreadsheets do, too.
The chance of the SQL committee picking some other meaning for bare
MEDIAN seems vanishingly small; although I have to grant that with
only Oracle and Sybas
Heikki Linnakangas writes:
> On 19/08/10 20:18, Tom Lane wrote:
>> But I'm still not seeing how this self-pipe hack avoids a race
>> condition. If the signal handler is sending a byte whenever it
>> executes, then you could have bytes already stacked up in the pipe
>> from previous interrupts tha
On Thu, Aug 19, 2010 at 01:25:36PM -0400, Tom Lane wrote:
> David Fetter writes:
> > On Thu, Aug 19, 2010 at 12:12:12PM -0500, Kevin Grittner wrote:
> >> http://www.merriam-webster.com/dictionary/median
> >>
> >> If you do a google search for "median" and poke around, you'll find
> >> many places
2010/8/19 David Fetter :
> On Thu, Aug 19, 2010 at 12:12:12PM -0500, Kevin Grittner wrote:
>> David Fetter wrote:
>>
>> > Median may be useful, but we pretty much can't just call it
>> > "median." Instead, we need to call it something like "left_median"
>> > or "arithmetic_median."
>>
>> I think i
2010/8/19 David Fetter :
> On Thu, Aug 19, 2010 at 12:49:45PM -0400, Robert Haas wrote:
>> On Thu, Aug 19, 2010 at 11:33 AM, Tom Lane wrote:
>> > Greg Stark writes:
>> >> On Thu, Aug 19, 2010 at 11:59 AM, Pavel Stehule
>> >> wrote:
>> >>> I am sending a prototype implementation of functions med
On 19/08/10 20:18, Tom Lane wrote:
Heikki Linnakangas writes:
On 19/08/10 19:57, Tom Lane wrote:
Hmm, but couldn't you still do that inside pg_usleep? Signal handlers
that do that couldn't know if they were interrupting a sleep per se,
so this would have to be a backend-wide convention.
I
David Fetter writes:
> On Thu, Aug 19, 2010 at 12:12:12PM -0500, Kevin Grittner wrote:
>> http://www.merriam-webster.com/dictionary/median
>>
>> If you do a google search for "median" and poke around, you'll find
>> many places where this is the only definition mentioned; the others
>> seem to be
Heikki Linnakangas writes:
> On 19/08/10 19:57, Tom Lane wrote:
>> Hmm, but couldn't you still do that inside pg_usleep? Signal handlers
>> that do that couldn't know if they were interrupting a sleep per se,
>> so this would have to be a backend-wide convention.
> I don't understand, do what in
On Thu, Aug 19, 2010 at 12:12:12PM -0500, Kevin Grittner wrote:
> David Fetter wrote:
>
> > Median may be useful, but we pretty much can't just call it
> > "median." Instead, we need to call it something like "left_median"
> > or "arithmetic_median."
>
> I think it would be reasonable, and per
David Fetter wrote:
> Median may be useful, but we pretty much can't just call it
> "median." Instead, we need to call it something like "left_median"
> or "arithmetic_median."
I think it would be reasonable, and perhaps preferable, to use just
"median" for the semantics described in most dict
On 19/08/10 19:57, Tom Lane wrote:
Heikki Linnakangas writes:
On 19/08/10 16:38, Tom Lane wrote:
Considering that pg_usleep is implemented with select, I'm not following
what you mean by "replace pg_usleep() with select()"?
Instead of using pg_usleep(), call select() directly, waiting not o
On Thu, Aug 19, 2010 at 12:49:45PM -0400, Robert Haas wrote:
> On Thu, Aug 19, 2010 at 11:33 AM, Tom Lane wrote:
> > Greg Stark writes:
> >> On Thu, Aug 19, 2010 at 11:59 AM, Pavel Stehule
> >> wrote:
> >>> I am sending a prototype implementation of functions median and
> >>> percentile. This i
Heikki Linnakangas writes:
> On 19/08/10 16:38, Tom Lane wrote:
>> Considering that pg_usleep is implemented with select, I'm not following
>> what you mean by "replace pg_usleep() with select()"?
> Instead of using pg_usleep(), call select() directly, waiting not only
> for the timeout, but als
On 19/08/10 18:08, Robert Haas wrote:
On Thu, Aug 19, 2010 at 9:47 AM, Tom Lane wrote:
Another possibility is for EXECUTE USING to coerce any unknowns to TEXT
before it calls the parser at all. This would square with the typical
default assumption for unknown literals, and it would avoid havin
Heikki Linnakangas writes:
> While testing the recent issue with unknown params in EXECUTE USING, I
> accidentally did this:
>EXECUTE 'SELECT ''foo'' || $1' USING 'bar' INTO t;
> The mistake I made? I put the USING and INTO clauses in wrong order,
> INTO needs to go first. We should throw
On Thu, Aug 19, 2010 at 11:33 AM, Tom Lane wrote:
> Greg Stark writes:
>> On Thu, Aug 19, 2010 at 11:59 AM, Pavel Stehule
>> wrote:
>>> I am sending a prototype implementation of functions median and
>>> percentile. This implementation is very simple and I moved it to
>>> contrib for this momen
On 19/08/10 16:38, Tom Lane wrote:
Heikki Linnakangas writes:
BTW, on what platforms signals don't interrupt sleep? Although that
issue has been discussed many times before, I couldn't find any
reference to a real platform in the archives.
I've got one in captivity (my old HPUX box). Happy t
On 19/08/10 18:08, Alvaro Herrera wrote:
Excerpts from Heikki Linnakangas's message of jue ago 19 02:02:34 -0400 2010:
On 19/08/10 04:46, Robert Haas wrote:
And so far we haven't seen a patch for that.
Somebody write one. And then let's get it reviewed and committed RSN.
Fujii is on vaca
On Thu, Aug 19, 2010 at 11:57 AM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Excerpts from Robert Haas's message of mié ago 18 21:32:48 -0400 2010:
>>> Here's v3.
>
>> The header comment in objectaddress.c contains a funny mistake: it says
>> it works with ObjectAddresses. However, ObjectAddres
Alvaro Herrera writes:
> Excerpts from Robert Haas's message of mié ago 18 21:32:48 -0400 2010:
>> Here's v3.
> The header comment in objectaddress.c contains a funny mistake: it says
> it works with ObjectAddresses. However, ObjectAddresses is a different
> type altogether, so I recommend not
On Thu, Aug 19, 2010 at 10:24:54PM +0800, Quan Zongliang wrote:
> documents attached. html and man-page
Thanks!
For future reference, the way to patch docs is by patching the SGML
source. Please find enclosed a patch which incorporates the code
patch you sent with these docs.
Cheers,
David.
--
Excerpts from Robert Haas's message of mié ago 18 21:32:48 -0400 2010:
> Here's v3.
The header comment in objectaddress.c contains a funny mistake: it says
it works with ObjectAddresses. However, ObjectAddresses is a different
type altogether, so I recommend not using that as plural for
ObjectAd
Greg Stark writes:
> On Thu, Aug 19, 2010 at 11:59 AM, Pavel Stehule
> wrote:
>> I am sending a prototype implementation of functions median and
>> percentile. This implementation is very simple and I moved it to
>> contrib for this moment - it is more easy maintainable. Later I'll
>> move it to
Hello,
I am using PostgreSQL 8.4 full text search in following way:
Custom FTS configuration called "dc2" with these dictionaries in
following order for asciihword token: latvian_ispell, english_stem,
russian_stem
Latvian ispell dictionary contains words with different endings but
same meaning
Excerpts from Heikki Linnakangas's message of jue ago 19 04:29:19 -0400 2010:
> While testing the recent issue with unknown params in EXECUTE USING, I
> accidentally did this:
>
> postgres=# DO $$
> DECLARE
>t text;
> BEGIN
>EXECUTE 'SELECT ''foo'' || $1' USING 'bar' INTO t;
>RAISE NO
On Thu, Aug 19, 2010 at 17:08, Alvaro Herrera
wrote:
> Excerpts from Heikki Linnakangas's message of jue ago 19 02:02:34 -0400 2010:
>> On 19/08/10 04:46, Robert Haas wrote:
>
>> > And so far we haven't seen a patch for that.
>> > Somebody write one. And then let's get it reviewed and committed
On Aug 19, 2010, at 8:08 AM, Robert Haas wrote:
>> Another possibility is for EXECUTE USING to coerce any unknowns to TEXT
>> before it calls the parser at all. This would square with the typical
>> default assumption for unknown literals, and it would avoid having to
>> have any semantics change
Excerpts from Heikki Linnakangas's message of jue ago 19 02:02:34 -0400 2010:
> On 19/08/10 04:46, Robert Haas wrote:
> > And so far we haven't seen a patch for that.
> > Somebody write one. And then let's get it reviewed and committed RSN.
>
> Fujii is on vacation, but I've started working on
On Thu, Aug 19, 2010 at 9:47 AM, Tom Lane wrote:
> Another possibility is for EXECUTE USING to coerce any unknowns to TEXT
> before it calls the parser at all. This would square with the typical
> default assumption for unknown literals, and it would avoid having to
> have any semantics changes b
On Thu, Aug 19, 2010 at 11:59 AM, Pavel Stehule wrote:
> I am sending a prototype implementation of functions median and
> percentile. This implementation is very simple and I moved it to
> contrib for this moment - it is more easy maintainable. Later I'll
> move it to core.
So if the entire resu
2010/8/19 David Fetter :
> On Thu, Aug 19, 2010 at 12:45:13PM +0200, Pavel Stehule wrote:
>> Hello
>>
>> > I'll test both variant first. Maybe there are not any significant
>> > difference between them. Now nodeAgg can build, fill a tuplesort.
>> > So I think is natural use it. It needs only one -
Heikki Linnakangas writes:
> I'm starting to wonder if it's worth enforcing the rule that all unknown
> Params must be coerced to the same target type. We could just document
> the behavior. Or maybe we should revert the whole thing, and add a check
> to PL/pgSQL EXECUTE USING code to just thro
On Thu, Aug 19, 2010 at 12:45:13PM +0200, Pavel Stehule wrote:
> Hello
>
> > I'll test both variant first. Maybe there are not any significant
> > difference between them. Now nodeAgg can build, fill a tuplesort.
> > So I think is natural use it. It needs only one - skip a calling a
> > transident
Heikki Linnakangas writes:
> BTW, on what platforms signals don't interrupt sleep? Although that
> issue has been discussed many times before, I couldn't find any
> reference to a real platform in the archives.
I've got one in captivity (my old HPUX box). Happy to test whatever you
come up wit
On Thu, Aug 19, 2010 at 4:29 AM, Heikki Linnakangas
wrote:
> While testing the recent issue with unknown params in EXECUTE USING, I
> accidentally did this:
>
> postgres=# DO $$
> DECLARE
> t text;
> BEGIN
> EXECUTE 'SELECT ''foo'' || $1' USING 'bar' INTO t;
> RAISE NOTICE '%', t;
> END;
> $$;
Hello
I am sending a prototype implementation of functions median and
percentile. This implementation is very simple and I moved it to
contrib for this moment - it is more easy maintainable. Later I'll
move it to core.
These functions are relative simple, there are not barrier for
implementation
Hello
>
> I'll test both variant first. Maybe there are not any significant
> difference between them. Now nodeAgg can build, fill a tuplesort. So I
> think is natural use it. It needs only one - skip a calling a
> transident function and directly call final function with external
> tuplesort. Min
On Thu, Aug 19, 2010 at 07:00, Michael Haggerty wrote:
> Magnus Hagander wrote:
>> Is there some way to make cvs2git work this way, and just not bother
>> even trying to create merge commits, or is that fundamentally
>> impossible and we need to look at another tool?
>
> The good news: (I just rem
While testing the recent issue with unknown params in EXECUTE USING, I
accidentally did this:
postgres=# DO $$
DECLARE
t text;
BEGIN
EXECUTE 'SELECT ''foo'' || $1' USING 'bar' INTO t;
RAISE NOTICE '%', t;
END;
$$;
NOTICE:
DO
The mistake I made? I put the USING and INTO clauses in wrong
On 18/08/10 18:03, Heikki Linnakangas wrote:
On 18/08/10 16:57, Tom Lane wrote:
hei...@postgresql.org (Heikki Linnakangas) writes:
Log Message:
---
Coerce 'unknown' type parameters to the right type in the fixed-params
parse_analyze() function. That case occurs e.g with PL/pgSQL
EXECUTE
75 matches
Mail list logo
