On Dec 17, 2010 8:02 AM, "Craig Ringer" wrote:
>
> On 16/12/10 21:01, Magnus Hagander wrote:
>
> > Found another problem in it: when running with an older version of
> > dbghelp.dll (which I was), it simply didn't work. We need to grab the
> > version of dbghelp.dll at runtime and pick which thing
On Thu, 2010-12-16 at 16:19 -0800, bricklen wrote:
> On Wed, Dec 15, 2010 at 2:39 AM, Simon Riggs wrote:
> > Perhaps a more useful definition would be
> >
> > EXCHANGE TABLE target WITH source;
> >
> > which just swaps the heap and indexes of each table.
>
> At the risk of stating the obvious, th
On 16/12/10 21:01, Magnus Hagander wrote:
> Found another problem in it: when running with an older version of
> dbghelp.dll (which I was), it simply didn't work. We need to grab the
> version of dbghelp.dll at runtime and pick which things we're going to
> dump based on that.
I was about to sugg
On Thu, Dec 16, 2010 at 20:24, David E. Wheeler wrote:
> On Dec 16, 2010, at 6:39 PM, Alex Hunsaker wrote:
>
>> You might argue this is a bug with URI::Escape as I *think* all uri's
>> will be utf8 encoded. Anyway, I think postgres is doing the right
>> thing here.
>
> No, URI::Escape is fine. Th
On Dec 16, 2010, at 6:39 PM, Alex Hunsaker wrote:
> You might argue this is a bug with URI::Escape as I *think* all uri's
> will be utf8 encoded. Anyway, I think postgres is doing the right
> thing here.
No, URI::Escape is fine. The issue is that if you don't decode text to Perl's
internal form
On Thu, 16 Dec 2010 19:35:56 +0900
Itagaki Takahiro wrote:
> On Thu, Dec 16, 2010 at 18:45, Shigeru HANADA
> wrote:
> > "COPY FROM" is a command which INSERT data from a file essentially,
> > so it requires RowExclusiveLock on the target table. On the other
> > hand, file_fdw is a feature which
On Wed, Dec 8, 2010 at 14:15, Oleg Bartunov wrote:
> On Wed, 8 Dec 2010, David E. Wheeler wrote:
>
>> On Dec 8, 2010, at 8:13 AM, Oleg Bartunov wrote:
>>
>>> adding utf8::decode($_[0]) solves the problem:
>> Hrm. Ideally all strings passed to PL/Perl functions would be decoded.
>
> yes, this is wh
2010/12/16 Alvaro Herrera :
> Excerpts from Daniel Popowich's message of mié dic 15 15:02:05 -0300 2010:
>
>> 1) Is there active work on window functions with frames over
>> interval ranges?
>
> Yeah, we had a patch for that but it was rejected; only ROWS was
> implemented. RANGE needed mor
On Thu, Dec 16, 2010 at 23:09, Robert Haas wrote:
> I believe that our project policy is that permissions checks must be
> done at execution time, not parse/plan time.
Oops, yes. I should have said "permission checks for foreign tables
should have done in their own execution". So, additional chec
On Wed, Dec 15, 2010 at 2:39 AM, Simon Riggs wrote:
> Perhaps a more useful definition would be
>
> EXCHANGE TABLE target WITH source;
>
> which just swaps the heap and indexes of each table.
At the risk of stating the obvious, this would work with partition exchange too?
--
Sent via pgsql-hack
On Thu, Dec 16, 2010 at 07:40:31AM -0500, Greg Smith wrote:
> David Fetter wrote:
> >That we're in the position of having prevN_wd for N = 1..5 as the
> >current code exists is a sign that we need to refactor the whole
> >thing, as you've suggested before.
> >
> >I'll work up a design and prototype
On Thursday 16 December 2010 21:41:10 Tom Lane wrote:
> Robert Haas writes:
> > On Thu, Dec 16, 2010 at 3:18 PM, Tom Lane wrote:
> >> I guess you misunderstood what I said. �What I meant was that we cannot
> >> longjmp *out to the outer level*, ie we cannot take control away from
> >> the input s
On 12/16/2010 03:52 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 12/16/2010 03:13 PM, Robert Haas wrote:
So how bad would it be if we committed this new format without support
for splitting large relations into multiple files, or with some stub
support that never actually gets used, and fix
On Thursday 16 December 2010 23:34:02 Heikki Linnakangas wrote:
> On 17.12.2010 00:29, Andres Freund wrote:
> > On Thursday 16 December 2010 19:33:10 Joachim Wieland wrote:
> >> On Thu, Dec 16, 2010 at 12:48 PM, Heikki Linnakangas
> >>
> >> wrote:
> >>> As soon as we have parallel pg_dump, the n
Magnus Hagander writes:
> Found another problem in it: when running with an older version of
> dbghelp.dll (which I was), it simply didn't work. We need to grab the
> version of dbghelp.dll at runtime and pick which things we're going to
> dump based on that.
> The attached version of the patch d
On 17.12.2010 00:29, Andres Freund wrote:
On Thursday 16 December 2010 19:33:10 Joachim Wieland wrote:
On Thu, Dec 16, 2010 at 12:48 PM, Heikki Linnakangas
wrote:
As soon as we have parallel pg_dump, the next big thing is going to be
parallel dump of the same table using multiple processes.
On Thursday 16 December 2010 19:33:10 Joachim Wieland wrote:
> On Thu, Dec 16, 2010 at 12:48 PM, Heikki Linnakangas
>
> wrote:
> > As soon as we have parallel pg_dump, the next big thing is going to be
> > parallel dump of the same table using multiple processes. Perhaps we
> > should prepare for
On Wed, Dec 15, 2010 at 10:11 AM, Alvaro Herrera
wrote:
> It occurs to me that we may need a new mode, which disconnects sessions
> that are not in a transaction (or as soon as they are) but leaves
> in-progress transactions alone; this could be the new default. Of
> course, this is much more dif
Dimitri Fontaine writes:
> Tom Lane writes:
>> However, the only way I can see to fix this "automatically" is to have
>> the makefiles propagate PG_VERSION_NUM (or one of the other values set
>> by configure) into generated control files.
>
> Ah, somewhat like what I was asked to remove from the
Gevik Babakhani writes:
> I was wondering if there has been anyone experimenting to compile PG
> using LLVM/clang compiler tools.
There is (or was, not sure if it's up right now) a buildfarm machine
using LLVM.
regards, tom lane
--
Sent via pgsql-hackers mailing list (p
Hi,
I was wondering if there has been anyone experimenting to compile PG
using LLVM/clang compiler tools.
Regards,
Gevik.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Excerpts from Tom Lane's message of jue dic 16 17:54:51 -0300 2010:
> Robert Haas writes:
> > On Thu, Dec 16, 2010 at 3:41 PM, Tom Lane wrote:
> >> (But this is all speculation; I don't actually know SSL innards.)
>
> > I would be really surprised if aborting a transaction takes long
> > enough
Robert Haas writes:
> On Thu, Dec 16, 2010 at 3:41 PM, Tom Lane wrote:
>> (But this is all speculation; I don't actually know SSL innards.)
> I would be really surprised if aborting a transaction takes long
> enough to mess up SSL. I mean, there could be a network delay at any
> time, too.
Yea
Andrew Dunstan writes:
> On 12/16/2010 03:13 PM, Robert Haas wrote:
>> So how bad would it be if we committed this new format without support
>> for splitting large relations into multiple files, or with some stub
>> support that never actually gets used, and fixed this later? Because
>> this is
On Thu, Dec 16, 2010 at 3:41 PM, Tom Lane wrote:
>> I thought the next thing we'd report would be the recovery
>> conflict, not any bizarre can't-abort-the-transaction scenario.
>
> Well, if we discard it because we're too lazy to implement error message
> merging, that's OK. Presumably it'll sti
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of jue dic 16 17:10:10 -0300 2010:
>> However, the only way I can see to fix this "automatically" is to have
>> the makefiles propagate PG_VERSION_NUM (or one of the other values set
>> by configure) into generated control files. I don't t
Robert Haas writes:
> On Thu, Dec 16, 2010 at 3:18 PM, Tom Lane wrote:
>> I guess you misunderstood what I said. What I meant was that we cannot
>> longjmp *out to the outer level*, ie we cannot take control away from
>> the input stack. We could however have a TRY block inside the interrupt
>>
Excerpts from Tom Lane's message of jue dic 16 17:10:10 -0300 2010:
> However, the only way I can see to fix this "automatically" is to have
> the makefiles propagate PG_VERSION_NUM (or one of the other values set
> by configure) into generated control files. I don't think that's what
> we want e
On Thu, Dec 16, 2010 at 3:18 PM, Tom Lane wrote:
> Robert Haas writes:
>> Hmm. It's seeming to me that what we want to do is something like this:
>
>> 1. If an error is thrown while DoingCommandRead, it gets upgraded to
>> FATAL. I don't think we have much choice about this because, per your
>>
On 12/16/2010 03:13 PM, Robert Haas wrote:
So how bad would it be if we committed this new format without support
for splitting large relations into multiple files, or with some stub
support that never actually gets used, and fixed this later? Because
this is starting to sound like a bigger pr
On 16.12.2010 22:13, Robert Haas wrote:
So how bad would it be if we committed this new format without support
for splitting large relations into multiple files, or with some stub
support that never actually gets used, and fixed this later? Because
this is starting to sound like a bigger project
Tom Lane writes:
> However, the only way I can see to fix this "automatically" is to have
> the makefiles propagate PG_VERSION_NUM (or one of the other values set
> by configure) into generated control files.
Ah, somewhat like what I was asked to remove from the patch, right?
-EXTVERSION = $(VER
Robert Haas writes:
> Hmm. It's seeming to me that what we want to do is something like this:
> 1. If an error is thrown while DoingCommandRead, it gets upgraded to
> FATAL. I don't think we have much choice about this because, per your
> previous comments, we can't longjmp() here without riski
On Thu, Dec 16, 2010 at 2:29 PM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> On 16.12.2010 20:33, Joachim Wieland wrote:
>>> How exactly would you "just split the table in chunks of roughly the
>>> same size" ?
>
>> Check pg_class.relpages, and divide that evenly across the processes.
>> That
On Thu, Dec 16, 2010 at 1:24 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Dec 16, 2010 at 12:46 PM, Tom Lane wrote:
Another thing I don't quite understand is - at what point does the
protocol allow us to emit an error?
>
>>> Basically, you can send an error in response to a que
Dimitri Fontaine writes:
> Alvaro Herrera writes:
>> I thought the suggestion of having "version = 9.1devel" line in each
>> contrib's module extension file was a joke. It is certainly not going
>> to be sustainable in the long run -- I don't think we want to be
>> modifying all control files ea
Alvaro Herrera writes:
> I thought the suggestion of having "version = 9.1devel" line in each
> contrib's module extension file was a joke. It is certainly not going
> to be sustainable in the long run -- I don't think we want to be
> modifying all control files each release. We need to find a b
Alvaro Herrera writes:
> I thought the suggestion of having "version = 9.1devel" line in each
> contrib's module extension file was a joke. It is certainly not going
> to be sustainable in the long run -- I don't think we want to be
> modifying all control files each release. We need to find a b
Heikki Linnakangas writes:
> On 16.12.2010 20:33, Joachim Wieland wrote:
>> How exactly would you "just split the table in chunks of roughly the
>> same size" ?
> Check pg_class.relpages, and divide that evenly across the processes.
> That should be good enough.
Not even close ... relpages coul
Excerpts from Dimitri Fontaine's message of jue dic 16 09:49:31 -0300 2010:
> Hi,
>
> Well $subject says about it all really. The bitrot of course comes from
> the fact that the last in-commitfest-dependency has been commited in,
> and I kept a version of pg_execute_sql_file() in the extension's p
=?utf-8?q?Rados=C5=82aw_Smogura?= writes:
> Tom Lane Thursday 16 December 2010 18:59:56
>> =?utf-8?q?Rados=C5=82aw_Smogura?= writes:
>>> ... This timestamp must be properly encoded
>>> depending if target is WITH TZ or not, but JDBC (and other clients,
>>> probably too) doesn't have any knowledg
Hello
I am resending a redesigned proposal about special plpgsql statement
that support iteration over an array.
The most conflict issue of last proposal was a syntax. It enhanced
relative complex FOR statement. So now, it's based on new statement
with simple syntax. We can use a keyword FOREACH,
On 16.12.2010 20:33, Joachim Wieland wrote:
On Thu, Dec 16, 2010 at 12:48 PM, Heikki Linnakangas
wrote:
As soon as we have parallel pg_dump, the next big thing is going to be
parallel dump of the same table using multiple processes. Perhaps we should
prepare for that in the directory archive f
On Thu, Dec 16, 2010 at 12:48 PM, Heikki Linnakangas
wrote:
> As soon as we have parallel pg_dump, the next big thing is going to be
> parallel dump of the same table using multiple processes. Perhaps we should
> prepare for that in the directory archive format, by allowing the data of a
> single
Robert Haas writes:
> On Thu, Dec 16, 2010 at 12:46 PM, Tom Lane wrote:
>>> Another thing I don't quite understand is - at what point does the
>>> protocol allow us to emit an error?
>> Basically, you can send an error in response to a query.
> What about some other message that's not a query?
Tom Lane Thursday 16 December 2010 18:59:56
> =?utf-8?q?Rados=C5=82aw_Smogura?= writes:
> > I work on binary support for JDBC. I saw disadventage of TIMESTAMPS WITH
> > / WITHOUT TZ. Currently (in text mode) driver always sends date time
> > string with appended time offset, as UNSPECIFIED so bac
December 16th, 2010: Celebrating 15 years of PostgreSQL, early.
Following on the smashing success of PostgreSQL Conference West,
PostgreSQL Conference West, The PostgreSQL Conference for Developers,
End Users and Decision Makers, is being held at the Hotel Pennsylvania,
in New York City from March
On 16.12.2010 19:58, Robert Haas wrote:
On Thu, Dec 16, 2010 at 12:48 PM, Heikki Linnakangas
wrote:
One more thing: the motivation behind this patch is to allow parallel
pg_dump in the future, so we should be make sure this patch caters well for
that.
As soon as we have parallel pg_dump, the
On Thu, Dec 16, 2010 at 12:46 PM, Tom Lane wrote:
> I'm handwaving there --- I think probably the
> first cut should just discard errors after the first, and see how
> well that works in practice.
Seems reasonable.
>> Another thing I don't quite understand is - at what point does the
>> protocol
=?utf-8?q?Rados=C5=82aw_Smogura?= writes:
> I work on binary support for JDBC. I saw disadventage of TIMESTAMPS WITH /
> WITHOUT TZ. Currently (in text mode) driver always sends date time string
> with
> appended time offset, as UNSPECIFIED so backend can choose to use offset or
> not. In bina
On Thu, Dec 16, 2010 at 12:48 PM, Heikki Linnakangas
wrote:
> One more thing: the motivation behind this patch is to allow parallel
> pg_dump in the future, so we should be make sure this patch caters well for
> that.
>
> As soon as we have parallel pg_dump, the next big thing is going to be
> par
Hi,
I work on binary support for JDBC. I saw disadventage of TIMESTAMPS WITH /
WITHOUT TZ. Currently (in text mode) driver always sends date time string with
appended time offset, as UNSPECIFIED so backend can choose to use offset or
not. In binary mode I can only send 8 bytes timestamp withou
On 16.12.2010 17:23, Heikki Linnakangas wrote:
On 16.12.2010 12:12, Greg Smith wrote:
There's a number of small things that I'd like to see improved in new
rev of this code
...
In addition to those:
...
One more thing: the motivation behind this patch is to allow parallel
pg_dump in the fut
Robert Haas writes:
> On Thu, Dec 16, 2010 at 11:58 AM, Tom Lane wrote:
>> It's possible we could refactor things so we abort the open transaction
>> while inside the interrupt handler, then queue up an error to be
>> reported whenever we next get a command (as envisioned in part 0003),
>> then j
On Dec 16, 2010, at 8:19 AM, Tom Lane wrote:
> I would think that we want to establish the same policy as we have for
> dictionary files: they're assumed to be UTF-8. I don't believe there
> should be an encoding option at all. If we didn't need one for
> dictionary files, there is *surely* no r
Andrew Dunstan writes:
> It's working, but I don't think it's right :-) In particular, I don't
> believe this, or rather I don't believe that its converse is false:
> /* If not HAVE_GETOPT, we are using src/port/getopt.c, which has
> optreset */
Yeah, that was a 90% solution. I had fir
On Thu, Dec 16, 2010 at 11:58 AM, Tom Lane wrote:
> Greg Smith writes:
>> I count four issues of various sizes left with this patch right now:
>
>> 1) This levels bit
>> 2) Can the approach used be simplified or the code made cleaner?
>> 3) What is the interaction with Hot Standby error handling?
Greg Smith writes:
> I count four issues of various sizes left with this patch right now:
> 1) This levels bit
> 2) Can the approach used be simplified or the code made cleaner?
> 3) What is the interaction with Hot Standby error handling?
> 4) The usual code formatting nitpicking, Kevin mentione
On 12/15/2010 11:53 PM, Tom Lane wrote:
OK, patch committed so we can get testing from the existing buildfarm
members, but please try on your new installation too.
It's working, but I don't think it's right :-) In particular, I don't
believe this, or rather I don't
Peter Eisentraut writes:
> Oddly, this doesn't work:
> create table test (x timestamp default localtimestamp at time zone 'UTC');
> ERROR: 42601: syntax error at or near "at"
> (Parentheses help.)
> The attached patch fixes it. Is there any reason for this omission?
I'm not really thrilled ab
And it *could* be used in exactly the case you're outlining as long as
you load the function dynamically.
Detecting the presence of a function does not require a version number.
If the symbol is in the library, use it.
The only reason the version number would come into play is if you were
Robert Haas writes:
> On Thu, Dec 16, 2010 at 9:04 AM, Dimitri Fontaine
> wrote:
Please note that the SQL scripts seem to be encoded in latin9.
>>> Seems like an odd choice. Why not UTF-8?
>> Not a choice, just what's already in
> Sure, I get it. I'm guessing that many of the scripts w
Magnus Hagander writes:
> On Thu, Dec 16, 2010 at 17:07, Tom Lane wrote:
>> because if you're trying to link against an older libpq, the link will
>> fail before you ever get to execute. So let's have a less implausible
>> use-case please.
> Look back at the very start of the thread.
OK, but l
On Thu, Dec 16, 2010 at 17:07, Tom Lane wrote:
> Magnus Hagander writes:
>> But it does outline that fact that it wouldn't suck to have a >function in
>> libpq returning the version so that application can >check this at runtime
>> - clearly it would also be useful when >being linked "through
Oddly, this doesn't work:
create table test (x timestamp default localtimestamp at time zone 'UTC');
ERROR: 42601: syntax error at or near "at"
(Parentheses help.)
The attached patch fixes it. Is there any reason for this omission?
(The patch also works in past releases, so it was not obvious
Magnus Hagander writes:
> But it does outline that fact that it wouldn't suck to have a >function in
> libpq returning the version so that application can >check this at runtime -
> clearly it would also be useful when >being linked "through" something like
> psycopg2.
> Stuck in a local git
Magnus, thats great ! And name PQlibVersion is correct ! Thanks.
2010/12/16 Magnus Hagander
> On Tue, Dec 14, 2010 at 17:56, Massa, Harald Armin wrote:
> >>> My question: Which way is available to query the linked libpq version?
> >
> >> But it does outline that fact that it wouldn't suck to ha
Tom Lane wrote:
> Magnus Hagander writes:
> > I get a crash on win32 when connecting to a server that's not started.
> > In fe-connect.c, we have:
>
> > display_host_addr = (conn->pghostaddr == NULL) &&
> > (strcmp(conn->pghost, host_addr) != 0);
>
> > In my case,
On Tue, Dec 14, 2010 at 17:56, Massa, Harald Armin wrote:
>>> My question: Which way is available to query the linked libpq version?
>
>> But it does outline that fact that it wouldn't suck to have a >function in
>> libpq returning the version so that application can >check this at runtime
>>
Magnus Hagander writes:
> On Thu, Dec 16, 2010 at 15:56, Tom Lane wrote:
>> I think the proposal for such a switch is unnecessary lily-gilding,
> Hmm. What we could do is have pg_ctl chdir() into the data directory
> on start.
See above. You're solving a problem that probably doesn't exist,
an
Magnus Hagander writes:
> On Thu, Dec 16, 2010 at 16:22, Tom Lane wrote:
>> Two connections are not really a problem IMO, so I would not be in favor
>> of kluging the API to the extent required by solution (B).
> (B) could be as simple as a callback asking for it, though, couldn't
> it? That see
Magnus Hagander writes:
> I get a crash on win32 when connecting to a server that's not started.
> In fe-connect.c, we have:
> display_host_addr = (conn->pghostaddr == NULL) &&
> (strcmp(conn->pghost, host_addr) != 0);
> In my case, conn->pghost is NULL at thi
On Thu, Dec 16, 2010 at 16:22, Tom Lane wrote:
> Tatsuo Ishii writes:
>> It seems psql(or libpq) connects to PostgreSQL twice when md5 auth is
>> required. Here is a strace log on my Linux machine. Is there any
>> reason for this? IMO frontend/backend protocol allows to send salt
>> after receiv
On 16.12.2010 12:12, Greg Smith wrote:
Moving onto the directory archive part of this patch, the feature seems
to work as advertised; here's a quick test case:
createdb pgbench
pgbench -i -s 1 pgbench
pg_dump -F d -f test
pg_restore -k test
pg_restore -l test
createdb copy
pg_restore -d copy tes
Tatsuo Ishii writes:
> It seems psql(or libpq) connects to PostgreSQL twice when md5 auth is
> required. Here is a strace log on my Linux machine. Is there any
> reason for this? IMO frontend/backend protocol allows to send salt
> after receiving AuthenticationMD5Password using the same socket. S
Magnus Hagander wrote:
> I get a crash on win32 when connecting to a server that's not started.
> In fe-connect.c, we have:
>
> display_host_addr = (conn->pghostaddr == NULL) &&
> (strcmp(conn->pghost, host_addr) != 0);
>
> In my case, conn->pghost is NULL at t
On Thu, Dec 16, 2010 at 15:56, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Dec 16, 2010 at 9:24 AM, Magnus Hagander wrote:
>>> We can do such a commandline. We don't have any platform-specific
>>> commandline options today. Is that something we've intentionally
>>> avoided, or just not need
Robert Haas writes:
> On Thu, Dec 16, 2010 at 9:24 AM, Magnus Hagander wrote:
>> We can do such a commandline. We don't have any platform-specific
>> commandline options today. Is that something we've intentionally
>> avoided, or just not needed before?
> Beats me.
Yes, it's something we intent
On Thu, Dec 16, 2010 at 9:24 AM, Magnus Hagander wrote:
> Is that less ugly? ;)
Well, I thought it was or I would have suggested it, but it's
obviously open to interpretation.
> But yes, we are talking about in the field, so it's fairly small. But
> any crash during guc loading for example would
On Thu, Dec 16, 2010 at 5:03 AM, Florian Pflug wrote:
> On Dec16, 2010, at 02:51 , Daniele Varrazzo wrote:
>> 1. do I get enough info in the PGresult to inspect anonymous composite types?
> You just get the composite value, as you discovered. In text mode, that means
> only the composite string va
On Thu, Dec 16, 2010 at 15:07, Robert Haas wrote:
> On Thu, Dec 16, 2010 at 8:01 AM, Magnus Hagander wrote:
>> We use the existance of the "crashdumps" directory as an indication we
>> want crashdumps. That's fine when the system is up. But what if we
>> crash *in the postmaster before we have do
On Thursday 16 December 2010 15:11:01 Simon Riggs wrote:
> In order to remove X1 we would need to change X0 to point to X2, which
> we don't do because we're not allowed to update in place. Even if we
> could, I'm not sure this case is frequent enough to be worth the effort.
Especially as X3 would
On Thu, Dec 16, 2010 at 14:01, Magnus Hagander wrote:
> On Thu, Dec 16, 2010 at 09:21, Craig Ringer
> wrote:
>> Hi all
>>
>> Updated patch attached. This one avoids the inline function stuff and
>> instead just decides whether to compile unix_crashdump.c or
>> win32_crashdump.c based on build sy
On Wednesday 15 December 2010 20:12:45 Robert Haas wrote:
> On Wed, Dec 15, 2010 at 10:02 AM, Andres Freund wrote:
> >> Is there a way that errstart() and/or errfinish() can know enough
> >> about the state of the communication with the frontend to decide
> >> whether to suppress edata->output_to_
2010/12/16 Robert Haas :
> On Thu, Dec 16, 2010 at 7:49 AM, Dimitri Fontaine
> wrote:
>
>> Please note that the SQL scripts seem to be encoded in latin9.
>
> Seems like an odd choice. Why not UTF-8?
Latin 9 = ISO 8859-15 = a more modern version of Latin 1 (ISO 8859-1),
which includes the € sym
On Wed, 2010-12-15 at 20:50 +0100, matteo durighetto wrote:
> if we continue the transaction and we do for example another update
> on this row (X) , we again redo the same operation:
>
>X0 (deleted "old" row)
>X1 (row inserted, NOW deleted) => not needed for rollback
>X2 (insert "
On Thu, Dec 16, 2010 at 5:35 AM, Itagaki Takahiro
wrote:
> Ah, I found my bug in BeginCopy(), but it's in the usage of
> ExecCheckRTPerms() rather than RowExclusiveLock, right?
> The target relation should have been opened and locked by the caller.
> I think we can move the check to DoCopy() as li
On Thu, Dec 16, 2010 at 9:04 AM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> On Thu, Dec 16, 2010 at 7:49 AM, Dimitri Fontaine
>> wrote:
>>> Please note that the SQL scripts seem to be encoded in latin9.
>>
>> Seems like an odd choice. Why not UTF-8?
>
> Not a choice, just what's already i
On Thu, Dec 16, 2010 at 8:01 AM, Magnus Hagander wrote:
> We use the existance of the "crashdumps" directory as an indication we
> want crashdumps. That's fine when the system is up. But what if we
> crash *in the postmaster before we have done chdir()*?
>
> Should we perhaps instead define a subd
Robert Haas writes:
> On Thu, Dec 16, 2010 at 7:49 AM, Dimitri Fontaine
> wrote:
>> Please note that the SQL scripts seem to be encoded in latin9.
>
> Seems like an odd choice. Why not UTF-8?
Not a choice, just what's already in…
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Exp
On Thu, Dec 16, 2010 at 7:49 AM, Dimitri Fontaine
wrote:
> Please note that the SQL scripts seem to be encoded in latin9.
Seems like an odd choice. Why not UTF-8?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list
On Thu, Dec 16, 2010 at 6:48 AM, Greg Smith wrote:
> I meant that I'd bundle it into the block of time I spend on that, and
> likely submit with something else that touches the same area. Obviously the
> correction patch would be better on its own when being handed over to a
> committer.
Oh, tha
Hi Greg,
On Thursday 16 December 2010 13:32:46 Greg Smith wrote:
> Andres Freund wrote:
> > On Thursday 02 December 2010 22:21:37 Alvaro Herrera wrote:
> >> Excerpts from Andres Freund's message of sáb oct 30 05:49:21 -0300 2010:
> >>> Ill set this up for the next commitfest, I don't think I can d
I get a crash on win32 when connecting to a server that's not started.
In fe-connect.c, we have:
display_host_addr = (conn->pghostaddr == NULL) &&
(strcmp(conn->pghost, host_addr) != 0);
In my case, conn->pghost is NULL at this point, as is
conn->pghostaddr
Tom Lane wrote:
- Writeable CTEs - I think we need Tom to pick this one up.
- Fix snapshot taking inconsistencies - Ready for committer. Can any
committer pick this up?
Will take a look at these two also.
I marked you down at the listed committer for them both. That leaves
"serial
Dimitri tells me there's a V18 of this patch due real soon now. That
may very well be ready for a committer, but even if that's the case it's
going to take them some time to consume what was at last count an almost
10K line long context diff. In the interest of closing this CF out
without fur
On Thu, Dec 16, 2010 at 09:21, Craig Ringer wrote:
> Hi all
>
> Updated patch attached. This one avoids the inline function stuff and
> instead just decides whether to compile unix_crashdump.c or
> win32_crashdump.c based on build system tests. It passes "make check" on
> nix and tests on win32, b
David Fetter wrote:
That we're in the position of having prevN_wd for N = 1..5 as the
current code exists is a sign that we need to refactor the whole
thing, as you've suggested before.
I'll work up a design and prototype for this by this weekend.
Great. I don't think issues around tab com
Andres Freund wrote:
On Thursday 02 December 2010 22:21:37 Alvaro Herrera wrote:
Excerpts from Andres Freund's message of sáb oct 30 05:49:21 -0300 2010:
Ill set this up for the next commitfest, I don't think I can do much
more without further input.
Are you reserving about 20
2010/12/16 Florian Pflug :
> On Dec13, 2010, at 08:23 , Pavel Stehule wrote:
>> There is a second possibility - and hardly simpler. We can use a
>> specialised statement with own parser/executor node. Then
>> implementation should be really simply
>>
>> syntax:
>>
>> EXTRACT_VALUE(expr1 FROM expr2
1 - 100 of 114 matches
Mail list logo
