On Wed, Aug 11, 2010 at 12:37 AM, Peter Geoghegan
wrote:
> On 10 August 2010 19:48, David E. Wheeler wrote:
>> On Aug 10, 2010, at 11:46 AM, Thom Brown wrote:
>>
>>> I, personally, would expect an empty array output given an empty
>>> input, and a null output for a null input.
>>
>> +1
>
> Agreed
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.
--
greg
--
Sent via pgsql-hacker
On Wed, Aug 11, 2010 at 12:51:36AM -0400, Greg Smith wrote:
> Andres Freund wrote:
> >The most prohibitively expensive part is the AtEOXact_Buffers
> >check of running through all buffers and checking their pin count.
> >And it makes $app's regression tests take thrice their time...
> Have you trie
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
trigger to each of the affected tabl
On Thu, 2010-06-10 at 23:18 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Thu, Jun 10, 2010 at 5:54 PM, Jim Nasby wrote:
> >> So there's no way to see if a particular privilege has been granted to
> >> public. ISTM 'public' should be accepted, since you can't use it as a role
> >> name an
On Wed, Aug 11, 2010 at 06:42, Tom Lane wrote:
> I am not sure if there's anything very good we can do about the
> problem of pg_regress misidentifying the postmaster it's managed to
> connect to. A real solution would probably be much more trouble than
> it's worth, anyway. However, it does se
On Wed, 2010-08-11 at 08:31 +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
> trigger to each of t
2010/8/11 Marko Tiikkaja :
> 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
On Wed, Aug 11, 2010 at 12:18 PM, Boxuan Zhai wrote:
>
>
> On Wed, Aug 11, 2010 at 12:14 PM, Greg Smith wrote:
>
>> Boxuan Zhai wrote:
>>
>>> I just found that no Assert() works in my codes. I think it is because
>>> the assertion is no enabled. How to enable assertion. To define
>>> USE_ASSERT_
On Sat, 2010-07-24 at 18:57 -0400, Joseph Adams 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, so people
On Tue, 2010-08-10 at 23:28 +0900, Fujii Masao wrote:
> ISTM the right is
>
> * Categorized into DEVELOPER_OPTIONS
> * The default is DEBUG1
> * The context is PGC_SIGHUP
Don't think we should go live with default of DEBUG1.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Development
On 10/08/10 12:38, Boxuan Zhai wrote:
These days I am considering what else can be done for MERGE, And, I
find inheritance tables in postgres is not supported by our MERGE command
yet.
I played with your latest patch version a bit, and actually, it seems to
me that inherited tables work just f
On Wed, Aug 11, 2010 at 5:26 PM, Simon Riggs wrote:
> On Tue, 2010-08-10 at 23:28 +0900, Fujii Masao wrote:
>
>> ISTM the right is
>>
>> * Categorized into DEVELOPER_OPTIONS
>> * The default is DEBUG1
>> * The context is PGC_SIGHUP
>
> Don't think we should go live with default of DEBUG1.
You thi
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. However, because the structure of
> > MERGE plan is much more complex
2010/8/11 Greg Stark :
> On Wed, Aug 11, 2010 at 12:37 AM, Peter Geoghegan
> wrote:
>> On 10 August 2010 19:48, David E. Wheeler wrote:
>>> On Aug 10, 2010, at 11:46 AM, Thom Brown wrote:
>>>
I, personally, would expect an empty array output given an empty
input, and a null output for a
On fre, 2010-08-06 at 10:28 +0300, Heikki Linnakangas wrote:
> IMO the UPDATE/DELETE/INSERT actions should fire the respective
> statement level triggers, but the MERGE itself should not.
Yes, SQL defines the triggering of triggers as part of the modification
of rows, not as part of any particula
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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscrip
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 you'd have to somehow make the constrain
On 11/08/10 11:45, 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. However, because the structure of
MERG
On Wed, Aug 11, 2010 at 3:57 AM, Simon Riggs wrote:
> On Thu, 2010-06-10 at 23:18 -0400, Tom Lane wrote:
>> Robert Haas writes:
>> > On Thu, Jun 10, 2010 at 5:54 PM, Jim Nasby wrote:
>> >> So there's no way to see if a particular privilege has been granted to
>> >> public. ISTM 'public' should
On 08/11/2010 12:42 AM, Tom Lane wrote:
There's an interesting buildfarm failure here:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=polecat&dt=2010-08-10%2023:46:10
It appears to me that this was caused by the concurrent run of another
buildfarm animal on the same physical machine, na
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 add support for
partitioning
Hello!
We have chosen another item from the list:
"Allow ALTER TABLE to change constraint deferrability and actions"
Is this already done? If yes, can you recommend any task which is
appropriate for beginners in open-source software?
Thanks in advance,
Chris & Viktor
2010/8/4 Bruce Momjian
Hi,
ResolveRecoveryConflictWithVirtualXIDs() calls pgstat_report_waiting(),
but it seems useless (though harmless) since the startup process doesn't
have the shared memory entry (i.e., MyBEEntry) for pg_stat_activity.
We should remove it?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE C
hello all ...
i am bugged with a small issue which is basically like this ...
test=# create table t_test as select x, x % 5 as y from generate_series(1,
100) AS x;
SELECT
test=# create index idx_a on t_test (x) ;
CREATE INDEX
test=# ANALYZE ;
ANALYZE
test=# explain analyze select * from
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Aug 11, 2010 at 3:57 AM, Simon Riggs wrote:
> > On Thu, 2010-06-10 at 23:18 -0400, Tom Lane wrote:
> >> Nothing. The only reason to use those forms is in a join against
> >> pg_authid, and the "public" group doesn't have an entry there.
> >
>
On Wed, Aug 11, 2010 at 4:27 PM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.com> wrote:
> On 10/08/10 12:38, Boxuan Zhai wrote:
>
>> These days I am considering what else can be done for MERGE, And, I
>> find inheritance tables in postgres is not supported by our MERGE command
>> yet.
>>
On Wed, 2010-08-11 at 06:48 -0400, Robert Haas wrote:
> On Wed, Aug 11, 2010 at 3:57 AM, Simon Riggs wrote:
> > On Thu, 2010-06-10 at 23:18 -0400, Tom Lane wrote:
> >> Robert Haas writes:
> >> > On Thu, Jun 10, 2010 at 5:54 PM, Jim Nasby wrote:
> >> >> So there's no way to see if a particular pr
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 ignored my proposal: lets do this in two
pieces. Get what we have now ready to commit
On Wed, 2010-08-11 at 14:21 +0200, Hans-Jürgen Schönig wrote:
> my question is: is there already a concept out there to make this work
> or does anybody know of a patch out there addressing an issue like
> that?
> some idea is heavily appreciated. it seems our sort key infrastructure
> is not enoug
On Tue, Aug 10, 2010 at 11:58 PM, Tom Lane wrote:
> The \e patch definitely needs another read-through. I noticed a number
> of comments that were still pretty poor English, and one ---
> /* skip header lines */
> --- that seems just plain wrong. The actual intent of that next bit is
> to
On Wed, Aug 11, 2010 at 8:51 AM, Simon Riggs wrote:
> On Wed, 2010-08-11 at 06:48 -0400, Robert Haas wrote:
>> On Wed, Aug 11, 2010 at 3:57 AM, Simon Riggs wrote:
>> > On Thu, 2010-06-10 at 23:18 -0400, Tom Lane wrote:
>> >> Robert Haas writes:
>> >> > On Thu, Jun 10, 2010 at 5:54 PM, Jim Nasby
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
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
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
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
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
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
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
--
"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
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
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 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
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 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
"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
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
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
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
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
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
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:
> 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 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
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'
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
>>
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_
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
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
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.
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
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
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
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, 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
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
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
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 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 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
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 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
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
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
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
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
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
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
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
"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 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
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
"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
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
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 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
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
> 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
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
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 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 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 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: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 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
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: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
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 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
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
1 - 100 of 132 matches
Mail list logo
