> I definitely agree that PL/pgsql could be more usable. Or if not,
> then some other PL with a better overall design could be more usable.
> I am not entirely sure how to create such a thing, however.
Would the standard plpsm be just that? Pavel maintains a pg implémentation of
it, I believe.
> Really?
>
> FOR var IN SELECT UNNEST(arr) LOOP ... END LOOP
>
> I mean, doing everything is sort of clunky in PL/pgsql, but this
> doesn't seem particularly bad as PL/pgsql idioms go.
>
this simple construction can take much more memory than other. I
proposed two or three years ago FOREACH state
2010/8/11 Robert Haas :
> On Wed, Aug 11, 2010 at 12:28 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Tue, Aug 10, 2010 at 11:58 PM, Tom Lane wrote:
BTW, at least in the usage in that loop, get_functiondef_dollarquote_tag
seems grossly overdesigned. It would be clearer, shorter, a
On Thu, Aug 12, 2010 at 12:49 AM, Greg Smith wrote:
> Tom Lane wrote:
>
>> Do we really think this is anywhere near committable now?
>>
>>
>
> There's a relatively objective standard for the first thing needed for
> commit--does it work?--in the form of the regression tests Simon put
> together b
On Wed, Aug 11, 2010 at 11:35 PM, Heikki Linnakangas
wrote:
> On 11/08/10 16:46, Robert Haas wrote:
>>
>> On Wed, Aug 11, 2010 at 1:17 AM, Fujii Masao
>> wrote:
>>>
>>> On Tue, Aug 10, 2010 at 9:30 AM, Robert Haas
>>> wrote:
It appears to me that RecordTransactionCommit() only needs to
Robert Haas writes:
> I suggest that we punt the \sf portion of this patch back for rework for
> the next CommitFest, and focus on getting the \e and \ef changes
> committed. I think the \sf code can be a lot simpler if we get rid of
> the code that's intended to recognize the ending delimeter.
On Wed, Aug 11, 2010 at 6:21 PM, Tom Lane wrote:
> Robert Haas writes:
>> ... If you're still unhappy with it, you're going to need to
>> be more specific, or hack on it yourself.
>
> I'm doing another pass over this. I notice that the documentation
> claims the syntax of \e is "\e [FILE] [LINE
On Wed, Aug 11, 2010 at 07:39:37PM -0400, Andrew Dunstan wrote:
> On 08/11/2010 07:33 PM, David Fetter wrote:
> >>I would be curious to the benefit of putting it in core. I have no
> >>problem with the type but in core?
> >If it's not in core, the vast majority of users will not have it
> >installe
Andrew Dunstan wrote:
>
>
> On 08/11/2010 07:33 PM, David Fetter wrote:
> >> I would be curious to the benefit of putting it in core. I have no
> >> problem with the type but in core?
> > If it's not in core, the vast majority of users will not have it
> > installed, and nothing, in core or other
On 11 August 2010 21:52, Tom Lane wrote:
> Peter Geoghegan writes:
>> What's wrong with something like array_is_empty(anyarray) returns
>> boolean?
>
> What's that got to do with iterating over an array?
Only that I'm of the opinion that we'd be well served by more array
convenience functions, i
On 08/11/2010 07:33 PM, David Fetter wrote:
I would be curious to the benefit of putting it in core. I have no
problem with the type but in core?
If it's not in core, the vast majority of users will not have it
installed, and nothing, in core or otherwise, will be able to count on
it.
You
On Wed, Aug 11, 2010 at 03:40:36PM -0700, Joshua D. Drake wrote:
> On Wed, 2010-08-11 at 15:27 -0700, David Fetter wrote:
> >
> > > I've been developing it as a contrib module because:
> > > * I'd imagine it's easier than developing it as a built-in
> > > datatype right away (e.g. editing a .sql.
On Wed, 2010-08-11 at 15:27 -0700, David Fetter wrote:
>
> > I've been developing it as a contrib module because:
> > * I'd imagine it's easier than developing it as a built-in datatype
> > right away (e.g. editing a .sql.in file versus editing pg_type.h ).
> > * As a module, it has PGXS support,
On Sat, Jul 24, 2010 at 06:57:18PM -0400, Joseph Adams wrote:
> Update: I'm in the middle of cleaning up the JSON code (
> http://git.postgresql.org/gitweb?p=json-datatype.git;a=summary if you
> want to see the very latest ), so I haven't addressed all of the major
> problems with it yet.
>
> On F
Robert Haas writes:
> ... If you're still unhappy with it, you're going to need to
> be more specific, or hack on it yourself.
I'm doing another pass over this. I notice that the documentation
claims the syntax of \e is "\e [FILE] [LINE]", but what is actually
implemented is "\e [FILE [LINE]]",
On Wed, Aug 11, 2010 at 4:21 PM, Peter Geoghegan
wrote:
> On 11 August 2010 18:53, Robert Haas wrote:
>>> I think that there's a need for additional built-in array functions,
>>> including one to succinctly test if an array has no elements.
>>
>> What do you propose? I think the easiest ways to
On 11/08/10 21:27, Tom Lane wrote:
Robert Haas writes:
On Mon, Aug 9, 2010 at 10:41 AM, Robert Haas wrote:
There's also the fact that it would probably end up parsing the data
twice. Given xmloption, I'm inclined to think Tom has it right:
provided xml_is_well_formed() that follows xmloption
On Wed, Aug 11, 2010 at 5:16 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 08/11/2010 04:47 PM, Tom Lane wrote:
>>> I prefer the change-the-default approach mainly because it wouldn't
>>> require any documentation,
>
>> Yeah. The other advantage is that we would not need to wait until we had
Andrew Dunstan writes:
> On 08/11/2010 04:47 PM, Tom Lane wrote:
>> I prefer the change-the-default approach mainly because it wouldn't
>> require any documentation,
> Yeah. The other advantage is that we would not need to wait until we had
> got everyone to update their versions of the buildfar
On 21/07/10 23:40, Magnus Hagander wrote:
I've also set up the git server and the scripts around it, that we can
eventually use. This includes commit email sending, commit policy enforcement
(no merge commits, correct author/committer tag etc) and proper access control
(a modified version of the
Peter Geoghegan writes:
> What's wrong with something like array_is_empty(anyarray) returns
> boolean?
What's that got to do with iterating over an array? We could certainly
provide it if it were commonly useful, but I'm not convinced of that.
regards, tom lane
--
Sent
On 08/11/2010 04:47 PM, Tom Lane wrote:
Andrew Dunstan writes:
Another way would be to have pg_regress honour an environment var like
PG_REGRESS_PORT, which the buildfarm script could use.
Yeah, that would work too. (Is it portable to Windows, though?)
Should be
I prefer the change-the-
Andrew Dunstan writes:
> Another way would be to have pg_regress honour an environment var like
> PG_REGRESS_PORT, which the buildfarm script could use.
Yeah, that would work too. (Is it portable to Windows, though?)
I prefer the change-the-default approach mainly because it wouldn't
require a
On 08/11/2010 04:17 PM, Tom Lane wrote:
We should have the
buildfarm configuration such that any one run uses the same port number
for both installed and uninstalled regression tests. If Peter is dead
set on not changing pg_regress's default, then changing the makefiles to
enable use of the --
Robert Haas writes:
> On Mon, Aug 9, 2010 at 10:41 AM, Robert Haas wrote:
>> There's also the fact that it would probably end up parsing the data
>> twice. Given xmloption, I'm inclined to think Tom has it right:
>> provided xml_is_well_formed() that follows xmloption, plus a specific
>> version
On 11 August 2010 18:53, Robert Haas wrote:
>> I think that there's a need for additional built-in array functions,
>> including one to succinctly test if an array has no elements.
>
> What do you propose? I think the easiest ways to do it right now are:
>
> array_length(arr, 1) is null
>
> or ju
Andrew Dunstan writes:
> You original email said:
> For some historic reasons, I have my local scripts set up so that
> they build development instances using the hardcoded port 65432.
> I think my response would be "Don't do that".
Yeah ... or at least use a different port per branch.
as tom pointed out - this is not possible.
there is no limit 20 in my case - i just used it to indicate that limiting does
not make the index scan possible which it does in some other cases.
the partial sort thing simon pointed out is what is needed at this point.
many thanks,
On 08/11/2010 02:12 PM, Peter Eisentraut wrote:
Even if you don't, changing this would only mean that you
couldn't safely run "make check" concurrently in multiple branches.
That's exactly the point. The original discussion is here:
http://archives.postgresql.org/message-id/491d9935.9010...
On 08/11/2010 02:39 PM, David E. Wheeler wrote:
On Aug 11, 2010, at 11:35 AM, Andrew Dunstan wrote:
for i in select array_subscripts(myarray, 1) loop ...
That's not a built-in function AFAIK.
Pavel pointed out to me only yesterday that it is:
http://www.postgresql.org/docs/current/stat
[moving discussion to -hackers]
Michael Meskes wrote:
> "Kevin Grittner" schrieb:
>>"Marcelo Mas" wrote:
>>
>>> Valgrind reports memmory leak when getting decimal data.
>>
>>I wonder how much overlap there is between this and the patch for
>>fixing ECPG memory leaks offered by Zoltán Böszörmé
On Aug 11, 2010, at 11:35 AM, Andrew Dunstan wrote:
>> for i in select array_subscripts(myarray, 1) loop ...
>
> That's not a built-in function AFAIK.
Pavel pointed out to me only yesterday that it is:
http://www.postgresql.org/docs/current/static/functions-srf.html#FUNCTIONS-SRF-SUBSCRIPTS
On 08/11/2010 01:59 PM, David E. Wheeler wrote:
On Aug 11, 2010, at 10:58 AM, Andrew Dunstan wrote:
for i in array_lower(myarray,1) .. array_upper(myarray,1) loop ...
works well
for i in select array_subscripts(myarray, 1) loop ...
That's not a built-in function AFAIK.
cheers
andrew
On 11/08/10 21:19, Daniel Oliveira wrote:
I wishing to create real big numbers, but I'm facing some difficulties.
Is possible to setup an integer type of more than 8 bytes (i.e. 16/32/48/64
bytes)?
No. Not unless you write your own datatype.
Use numeric, it scales up to ridiculously large num
Hello,
I wishing to create real big numbers, but I'm facing some difficulties.
Is possible to setup an integer type of more than 8 bytes (i.e. 16/32/48/64
bytes)?
Can I setup a value as large as I want?
How I should acess them using PG_RETURN_xxx and PG_GETARG_xxx macros?
Thanks in advance,
D
On ons, 2010-08-11 at 11:47 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > On ons, 2010-08-11 at 10:15 -0400, Tom Lane wrote:
> >> How about just this:
> >>port = 0xC000 | (DEF_PGPORT & 0x3FFF);
>
> > The version number was put in there intentionally, for developers who
> > work on mul
Excerpts from Heikki Linnakangas's message of mié ago 11 10:52:24 -0400 2010:
> On 11/08/10 17:45, Simon Riggs wrote:
> > We've seen it time and time again
> > that big projects that aim to deliver towards end of a release cycle
> > interfere with dev of other projects and leave loose ends from
>
On ons, 2010-08-11 at 11:53 -0400, Andrew Dunstan wrote:
> > The version number was put in there intentionally, for developers
> who
> > work on multiple branches at once. That's the whole reason this
> code
> > exists. Please don't remove it.
> >
>
> Do they run "make check" by hand simultaneou
On Aug 11, 2010, at 10:58 AM, Andrew Dunstan wrote:
> for i in array_lower(myarray,1) .. array_upper(myarray,1) loop ...
>
> works well
for i in select array_subscripts(myarray, 1) loop ...
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
On 08/11/2010 01:54 PM, David E. Wheeler wrote:
On Aug 11, 2010, at 10:53 AM, Robert Haas wrote:
Iterating through an array with plpgsql, for example, is more clunky
than it should be.
Really?
FOR var IN SELECT UNNEST(arr) LOOP ... END LOOP
I mean, doing everything is sort of clunky in PL/
On Aug 11, 2010, at 10:53 AM, Robert Haas wrote:
>> Iterating through an array with plpgsql, for example, is more clunky
>> than it should be.
>
> Really?
>
> FOR var IN SELECT UNNEST(arr) LOOP ... END LOOP
>
> I mean, doing everything is sort of clunky in PL/pgsql, but this
> doesn't seem part
On Wed, Aug 11, 2010 at 1:32 PM, Peter Geoghegan
wrote:
>> Yeah, I think David's examples are talking about the behavior of join,
>> but we're trying to decide what split should do. I think the main
>> argument for making it return NULL is that you can then fairly easily
>> use COALESCE() to get
On Aug 11, 2010, at 9:40 AM, Robert Haas wrote:
> Yeah, I think David's examples are talking about the behavior of join,
> but we're trying to decide what split should do.
Right, sorry about that.
> I think the main
> argument for making it return NULL is that you can then fairly easily
> use
On Aug 11, 2010, at 9:36 AM, Tom Lane wrote:
>>
>> I believe those are all "", rather than '"' + undef + '"'.
>
> If you believe my previous opinion that the design center for these
> functions is arrays of numbers, then a zero-entry text[] array is what
> you want, because you can successfully
> Yeah, I think David's examples are talking about the behavior of join,
> but we're trying to decide what split should do. I think the main
> argument for making it return NULL is that you can then fairly easily
> use COALESCE() to get whatever you want. That's a bit more difficult
> if you use
Tom Lane wrote:
Do we really think this is anywhere near committable now?
There's a relatively objective standard for the first thing needed for
commit--does it work?--in the form of the regression tests Simon put
together before development. I just tried the latest merge_v102.patch
(reg
On Mon, Aug 9, 2010 at 10:41 AM, Robert Haas wrote:
> On Mon, Aug 9, 2010 at 10:20 AM, Peter Eisentraut wrote:
>> On lör, 2010-08-07 at 16:47 +0100, Mike Fowler wrote:
>>> To be honest I'm happiest with returning a boolean, even if there is
>>> some confusion over content only being valid. Though
On Wed, Aug 11, 2010 at 12:36 PM, Tom Lane wrote:
> "David E. Wheeler" writes:
>> On Aug 11, 2010, at 7:41 AM, Tom Lane wrote:
>>> So maybe we need to revisit the issue. Pavel was claiming that
>>> switching to a zero-element array result was a no-brainer, but evidently
>>> it isn't so. Is anyb
On Wed, Aug 11, 2010 at 12:28 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Aug 10, 2010 at 11:58 PM, Tom Lane wrote:
>>> BTW, at least in the usage in that loop, get_functiondef_dollarquote_tag
>>> seems grossly overdesigned. It would be clearer, shorter, and faster if
>>> you just had
"David E. Wheeler" writes:
> On Aug 11, 2010, at 7:41 AM, Tom Lane wrote:
>> So maybe we need to revisit the issue. Pavel was claiming that
>> switching to a zero-element array result was a no-brainer, but evidently
>> it isn't so. Is anybody still excited about the alternatives?
> % perl -E 's
Robert Haas writes:
> On Tue, Aug 10, 2010 at 11:58 PM, Tom Lane wrote:
>> BTW, at least in the usage in that loop, get_functiondef_dollarquote_tag
>> seems grossly overdesigned. It would be clearer, shorter, and faster if
>> you just had a strncmp test for "AS $function" there.
> As far as I c
On Aug 11, 2010, at 7:41 AM, Tom Lane wrote:
> I had forgotten that discussion. It looks like we trailed off without
> any real consensus: there was about equal sentiment for an array with
> zero elements and an array with one empty-string element. We ended
> up leaving it alone because (a) that
"Kevin Grittner" writes:
> Peter Eisentraut wrote:
>> Why not just compare pg_backend_pid() with postmaster.pid?
> See the prior discussion in the archives. We started with that and
> found problems, to which Tom suggested a random number as the best
> solution.
I think Peter's idea is a bit
On ons, 2010-08-11 at 11:48 -0400, Tom Lane wrote:
> How's that help? pg_backend_pid isn't going to return the
> postmaster's
> PID ... maybe we could add a new function that does return the
> postmaster's PID, though.
Hmm, is there a portable way to find the parent PID of some other
process, giv
On 08/11/2010 11:42 AM, Peter Eisentraut wrote:
On ons, 2010-08-11 at 10:15 -0400, Tom Lane wrote:
One of us is missing something. I didn't say to run the checks using
the
configured port. I had in mind something like:
port = 0xC000 | ((PG_VERSION_NUM + DEF_PGPORT)& 0x3FFF);
Oh, I s
Peter Eisentraut wrote:
> On ons, 2010-08-11 at 09:55 -0400, Tom Lane wrote:
>> BTW, I don't know why anyone would think that "a random number"
>> would offer any advantage here. I'd use the postmaster PID,
>> which is guaranteed to be unique across the space that you're
>> worried about. In fac
Peter Eisentraut writes:
> On ons, 2010-08-11 at 10:15 -0400, Tom Lane wrote:
>> How about just this:
>> port = 0xC000 | (DEF_PGPORT & 0x3FFF);
> The version number was put in there intentionally, for developers who
> work on multiple branches at once. That's the whole reason this code
> ex
On ons, 2010-08-11 at 10:47 -0400, Tom Lane wrote:
> > I thought the point of ASSERTIONs was that you could write a thing
> such as:
> > CREATE ASSERTION foo CHECK ((SELECT count(*) FROM tbl) = 4);
> > Enforcing that kind of constraints without true serializability
> seems
> > impractical.
>
> En
2010/8/11 Boszormenyi Zoltan :
> Shouldn't it at least be documented in more depth? Say, get_bit(, N)
> provides the Nth bit (0-based) counting from the leftmost bit?
> I would certainly appreciate a warning spelled out about this
> so if you convert a number to bitstring of length N and you want t
Peter Eisentraut writes:
> On ons, 2010-08-11 at 09:55 -0400, Tom Lane wrote:
>> BTW, I don't know why anyone would think that "a random number" would
>> offer any advantage here. I'd use the postmaster PID, which is
>> guaranteed to be unique across the space that you're worried about.
>> In fac
On ons, 2010-08-11 at 13:23 +0300, Marko Tiikkaja wrote:
> But you'd have to somehow make the constraints to be checked
> with true serializability, and that part of the original suggestion
> seemed to be completely missing. Not sure how hard that would be
> though.
I don't think somehow runnin
On ons, 2010-08-11 at 09:55 -0400, Tom Lane wrote:
> BTW, I don't know why anyone would think that "a random number" would
> offer any advantage here. I'd use the postmaster PID, which is
> guaranteed to be unique across the space that you're worried about.
> In fact, you could implement this off
On ons, 2010-08-11 at 10:15 -0400, Tom Lane wrote:
> > One of us is missing something. I didn't say to run the checks using
> the
> > configured port. I had in mind something like:
>
> > port = 0xC000 | ((PG_VERSION_NUM + DEF_PGPORT) & 0x3FFF);
>
> Oh, I see, modify the DEF_PGPORT don't ju
Robert Haas writes:
> On Wed, Aug 11, 2010 at 11:23 AM, Simon Riggs wrote:
>> Well, if we go off chasing this particular goose then we will set
>> ourselves back at least one commitfest. I'd rather work towards having a
>> fully committable patch without inheritance sooner than an even bigger
>>
On 08/11/2010 10:23 AM, Robert Haas wrote:
Or we could do something like
port = 0xC000 ^ (DEF_PGPORT& 0x7FFF);
which is absolutely guaranteed not to conflict with DEF_PGPORT, at the
cost of possibly shifting into the 32K-48K port number range if you
had set DEF_PGPORT above 48K.
I li
Robert Haas writes:
> On Wed, Aug 11, 2010 at 10:15 AM, Tom Lane wrote:
>> Or we could do something like
>>
>> port = 0xC000 ^ (DEF_PGPORT & 0x7FFF);
>>
>> which is absolutely guaranteed not to conflict with DEF_PGPORT, at the
>> cost of possibly shifting into the 32K-48K port number range
Alvaro Herrera writes:
> Excerpts from Hans-Jürgen Schönig's message of mié ago 11 08:21:10 -0400
> 2010:
>> test=# explain analyze select * from t_test order by x, y limit 20;
> But if you put the limit in a subquery which is ordered by the
> known-indexed condition, it is very fast:
> alvh
On Wed, Aug 11, 2010 at 11:23 AM, Simon Riggs wrote:
> Well, if we go off chasing this particular goose then we will set
> ourselves back at least one commitfest. I'd rather work towards having a
> fully committable patch without inheritance sooner than an even bigger
> patch arriving later in the
Excerpts from Hans-Jürgen Schönig's message of mié ago 11 08:21:10 -0400 2010:
> same with limit ...
>
>
> test=# explain analyze select * from t_test order by x, y limit 20;
But if you put the limit in a subquery which is ordered by the
known-indexed condition, it is very fast:
alvherre=# exp
On Wed, 2010-08-11 at 11:03 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On Wed, 2010-08-11 at 13:25 +0300, Heikki Linnakangas wrote:
> >> I concur that Boxuan's suggested "difficult" approach seems like the
> >> right one.
>
> > Right, but you've completely ignored my proposal: lets do thi
On fre, 2010-08-06 at 08:12 +0100, Simon Riggs wrote:
> Given that Peter is now attending SQL Standards meetings, I would
> suggest we leave out my suggestion above, for now. We have time to
> raise this at standards meetings and influence the outcome and then
> follow later.
I'm not actually atte
Simon Riggs writes:
> On Wed, 2010-08-11 at 13:25 +0300, Heikki Linnakangas wrote:
>> I concur that Boxuan's suggested "difficult" approach seems like the
>> right one.
> Right, but you've completely ignored my proposal: lets do this in two
> pieces. Get what we have now ready to commit, then a
Vik Reykja writes:
> We just put in the possibility to name the client connections. Would it be
> interesting to be able to name the server installation itself?
Wouldn't do anything for this problem --- it would just introduce
something else the buildfarm would have to worry about uniqueness of.
Robert Haas writes:
> On Wed, Aug 11, 2010 at 8:51 AM, Simon Riggs wrote:
>> It clearly rates higher in importance than most of the things on the
>> open items list of late...
> First, I don't think that's true. WALreceiver crashing on AIX, the
> backup procedure in the manual possibly being wr
On 11/08/10 17:45, Simon Riggs wrote:
It seems clear that your work in this area will interfere with the work
on partitioning and insert routing.
Nothing concrete has come out of that work yet. And we should have MERGE
work with inherited tables, regardless of any future work that may
happen
On Wed, Aug 11, 2010 at 10:32 AM, Tom Lane wrote:
> Greg Stark writes:
>> Ideally you really want string_to_array(array_to_string(x, ':'),':')
>> to return x. There's no safe return value to pick for the cases where
>> x=[''] and x=[] that will make this work.
>
> It's easy to see that string_to_
Marko Tiikkaja writes:
> On 8/11/10 8:31 AM +0300, Peter Eisentraut wrote:
>> Thinking about SQL assertions (check constraints that are independent of
>> one particular table), do you think it would be reasonable to implement
>> those on top of constraint triggers? On creation you'd hook up a
>>
Ok..in response to the questions from Heikki,
1. Yes, "contrib/dblink" does work. Here's the output from the command used to
"make" dblink:
postgres:thimar> /usr/bin/gmake -C contrib/dblink install
gmake: Entering directory
`/dinabkp/faouzis/postgresql-9.0beta1/contrib/dblink'
On Wed, 2010-08-11 at 22:09 +0800, Boxuan Zhai wrote:
> One more thing I want to point out is that, the INSERT is also an
> inheritable action in MERGE. For a plain INSERT command, all the
> inserted tuples are put in the target table ONLY. It is easy to
> understand. We don't want to duplicate a
Greg Stark writes:
> There's already been one rather-long thread on this topic.
> http://thread.gmane.org/gmane.comp.db.postgresql.general/121450
> In there I argue for the empty array interpretation and Tom goes back
> and forth a few times. I'm not sure where that thread ended though.
I had fo
On 11/08/10 16:46, Robert Haas wrote:
On Wed, Aug 11, 2010 at 1:17 AM, Fujii Masao wrote:
On Tue, Aug 10, 2010 at 9:30 AM, Robert Haas wrote:
It appears to me that RecordTransactionCommit() only needs to WAL-log
shared invalidation messages when wal_level is hot_standby, but I
don't see a gua
Greg Stark writes:
> Ideally you really want string_to_array(array_to_string(x, ':'),':')
> to return x. There's no safe return value to pick for the cases where
> x=[''] and x=[] that will make this work.
It's easy to see that string_to_array/array_to_string are *not* usable
as general-purpose s
Marko Tiikkaja wrote:
> On 8/11/10 1:18 PM +0300, Peter Eisentraut wrote:
>> On ons, 2010-08-11 at 10:54 +0300, Marko Tiikkaja wrote:
>>> Enforcing that kind of constraints without true serializability
>>> seems impractical.
>>
>> Yes, but that is being worked on, I understand.
>
> Correct. But
On Wed, Aug 11, 2010 at 10:20 AM, Alanoly Andrews wrote:
> Ok..in response to the questions from Heikki,
>
> 1. Yes, "contrib/dblink" does work. Here's the output from the command used
> to "make" dblink:
> postgres:thimar> /usr/bin/gmake -C contrib/dblink install
> gmake: Entering dire
On Wed, Aug 11, 2010 at 10:15 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 08/11/2010 09:43 AM, Tom Lane wrote:
>>> Andrew Dunstan writes:
Why not just add the configured port (DEF_PGPORT) into the calculation
of the port to run on?
>
>>> No, that would be just about the worst po
Andrew Dunstan writes:
> On 08/11/2010 09:43 AM, Tom Lane wrote:
>> Andrew Dunstan writes:
>>> Why not just add the configured port (DEF_PGPORT) into the calculation
>>> of the port to run on?
>> No, that would be just about the worst possible choice. It'd be
>> guaranteed to fail in the standa
"Kevin Grittner" writes:
> Tom Lane wrote:
>> BTW, I don't know why anyone would think that "a random number"
>> would offer any advantage here. I'd use the postmaster PID, which
>> is guaranteed to be unique across the space that you're worried
>> about.
> Well, in the post I cited, it was yo
On Wed, Aug 11, 2010 at 10:09 AM, Boxuan Zhai wrote:
> PS: Since I have taken this project, I will do my best to make it perfect.
> I will keep working on MERGE until it is really finished, even after the
> gSoC. (unless you guys has other plans).
That is great to hear!
FWIW, I agree with Heikki
On Fri, Aug 6, 2010 at 3:53 PM, Heikki Linnakangas
wrote:
> So, loading libpqwalreceiver library crashes. It looks like it might be
> pthread-related. Perhaps something wrong with our makefiles, causing
> libpqwalreceiver to be built with wrong flags? Does contrib/dblink work? If
> you look at the
On Wed, Aug 11, 2010 at 4:45 PM, Simon Riggs wrote:
> On Tue, 2010-08-10 at 17:15 +0300, Heikki Linnakangas wrote:
> > On 10/08/10 12:38, Boxuan Zhai wrote:
> > > The difficult way is to generate the plans for children table in
> planner, as
> > > the other commands like UPDATE and DELETE. Howev
Tom Lane wrote:
> BTW, I don't know why anyone would think that "a random number"
> would offer any advantage here. I'd use the postmaster PID, which
> is guaranteed to be unique across the space that you're worried
> about.
Well, in the post I cited, it was you who argued that the PID was a
On 08/11/2010 09:43 AM, Tom Lane wrote:
Andrew Dunstan writes:
On 08/11/2010 12:42 AM, Tom Lane wrote:
... However, it does seem like we ought to be able to
do something about two buildfarm critters defaulting to the same choice
of port number.
Why not just add the configured port (DEF_PGP
"Kevin Grittner" writes:
> Tom Lane wrote:
>> A look at the code shows that it is merely trying to run psql, and
>> if psql reports that it can connect to the specified port, then
>> pg_regress thinks the postmaster started OK. Of course, psql was
>> really reporting that it could connect to the
Hi,
I just came across the following confusing thing.
zozo=# create table bit_test(i integer);
CREATE TABLE
zozo=# insert into bit_test values (1), (2), (3);
INSERT 0 3
zozo=# select i, i::bit(2), get_bit(i::bit(2), 1) as bit1,
get_bit(i::bit(2), 0) as bit0 from bit_test;
i | i | bit1 | bit0
--
On Wed, Aug 11, 2010 at 1:17 AM, Fujii Masao wrote:
> On Tue, Aug 10, 2010 at 9:30 AM, Robert Haas wrote:
>> It appears to me that RecordTransactionCommit() only needs to WAL-log
>> shared invalidation messages when wal_level is hot_standby, but I
>> don't see a guard to prevent it from doing it
Tom Lane wrote:
> A look at the code shows that it is merely trying to run psql, and
> if psql reports that it can connect to the specified port, then
> pg_regress thinks the postmaster started OK. Of course, psql was
> really reporting that it could connect to the other instance's
> postmaster
Andrew Dunstan writes:
> On 08/11/2010 12:42 AM, Tom Lane wrote:
>> ... However, it does seem like we ought to be able to
>> do something about two buildfarm critters defaulting to the same choice
>> of port number.
> Why not just add the configured port (DEF_PGPORT) into the calculation
> of t
Robert Haas wrote:
> What does the TODO list item mean by "and actions"?
Things like ON DELETE CASCADE versus ON DELETE RESTRICT?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hack
On Wed, 2010-08-11 at 15:53 +0300, Heikki Linnakangas wrote:
> On 11/08/10 14:44, Simon Riggs wrote:
> > On Wed, 2010-08-11 at 13:25 +0300, Heikki Linnakangas wrote:
> >
> >> I concur that Boxuan's suggested "difficult" approach seems like the
> >> right one.
> >
> > Right, but you've completely ig
On Wed, Aug 11, 2010 at 7:47 AM, Viktor Valy wrote:
> We have chosen another item from the list:
> "Allow ALTER TABLE to change constraint deferrability and actions"
I believe that is not done. What does the TODO list item mean by "and actions"?
--
Robert Haas
EnterpriseDB: http://www.enterpri
1 - 100 of 132 matches
Mail list logo
