IMHO the current behavior is broken:
decibel@decina:[17:46]~/pgsql/HEAD/i$bin/psql -c 'select 1' -c 'select 2'
?column?
--
2
(1 row)
Another try with one -c but with similar results:
sh> psql -c "SELECT 1; SELECT 'hello';"
?column?
--
hello
(1 row)
On 17 October 2013 03:29, Peter Eisentraut wrote:
> On Mon, 2013-07-08 at 16:04 +, Dean Rasheed wrote:
>> There was concern that pg_relation_is_updatable() would end up opening
>> every relation in the database, hammering performance. I now realise
>> that these tab-complete queries have a lim
On Wed, Oct 16, 2013 at 5:55 PM, Stéphan BEUZE
wrote:
> The following query is performed concurrently by two threads logged in with
> two different users:
>
> WITH raw_stat AS (
> SELECT
>host(client_addr) as client_addr,
>pid ,
>usename
> FR
On Wed, Oct 16, 2013 at 1:34 PM, Josh Berkus wrote:
> Jaime,
>> = Building =
>>
>> In pg_basebackup we have now 2 unused functions:
>> escapeConnectionParameter and escape_quotes. the only use of these
>> functions was when that tool created the recovery.conf file so they
>> aren't needed anymore.
IMHO the current behavior is broken:
decibel@decina:[17:46]~/pgsql/HEAD/i$bin/psql -c 'select 1' -c 'select 2'
?column?
--
2
(1 row)
I would expect psql to either run both commands or throw an error.
What I'd personally prefer is that psql execute -c and -f (and arguably -v) i
On 2013-10-17 18:04:34 -0400, Noah Misch wrote:
> On Thu, Oct 17, 2013 at 08:27:01PM +0200, Andres Freund wrote:
> > On 2013-10-17 12:33:45 -0400, Noah Misch wrote:
> > > > 1. Is there any guarantee that sizeof(intptr_t) >= sizeof(size_t)?
> > > > (Note that Size is just a typedef for size_t, in c.
On Thu, Oct 17, 2013 at 08:27:01PM +0200, Andres Freund wrote:
> On 2013-10-17 12:33:45 -0400, Noah Misch wrote:
> > > 1. Is there any guarantee that sizeof(intptr_t) >= sizeof(size_t)?
> > > (Note that Size is just a typedef for size_t, in c.h)
> >
> > C99 doesn't require it, but I have never hea
On 10/17/13 12:45 PM, Robert Haas wrote:
> The attached patch, which I propose to apply relatively soon if nobody
> objects, removes the IRIX port.
+1
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/p
On 10/17/2013 06:59 PM, Josh Berkus wrote:
> Our project has a serious, chronic problem with giving new
> patch-submitters a bad experience, and this patch is a good example of
> that. The ultimate result is that people go off to contribute to other
> projects where submissions are easier and the
On 10/17/2013 08:36 PM, Kevin Grittner wrote:
> Josh Berkus wrote:
>
>> Our project has a serious, chronic problem with giving new
>> patch-submitters a bad experience, and this patch is a good
>> example of that.
> Perhaps; but it has also been an example of the benefits of having
> tight review.
On Thu, Oct 17, 2013 at 7:22 AM, Robert Haas wrote:
> On Wed, Oct 16, 2013 at 5:14 PM, Josh Berkus wrote:
>> On 10/16/2013 01:25 PM, Andrew Dunstan wrote:
>>> Andres has just been politely pointing out to me that my knowledge of
>>> memory allocators is a little out of date (i.e. by a decade or t
On 10/17/2013 10:33 AM, Jeff Janes wrote:
A lot. A whole lot, more than what most people have in production
with more than that. You are forgetting a very large segment of the
population who run... VMs.
Why don't we just have 3 default config files:
2GB memory
4GB memo
Josh Berkus wrote:
> Our project has a serious, chronic problem with giving new
> patch-submitters a bad experience, and this patch is a good
> example of that.
Perhaps; but it has also been an example of the benefits of having
tight review. IMO, pg_sleep_for() and pg_sleep_until() are better
t
On 2013-10-17 12:33:45 -0400, Noah Misch wrote:
> > But if we're bent on minimizing the use of 64-bit arithmetic on 32-bit
> > systems, then presumably I should instead go back and retrofit that
> > patch to use Size rather than uint64 to represent the size of a
> > segment. But then I have two co
On Thu, Oct 17, 2013 at 12:33 PM, Noah Misch wrote:
>> But if we're bent on minimizing the use of 64-bit arithmetic on 32-bit
>> systems, then presumably I should instead go back and retrofit that
>> patch to use Size rather than uint64 to represent the size of a
>> segment. But then I have two c
On Thu, Oct 17, 2013 at 1:10 PM, Josh Berkus wrote:
> On 10/17/2013 10:01 AM, Robert Haas wrote:
>> But if you're asking my opinion, I think doing it on the function
>> level is a whole lot better and easier to get right. A flag like the
>> one I mentioned here can be set for one particular funct
On Thu, Oct 17, 2013 at 12:59 PM, Josh Berkus wrote:
> Now, I do think the argument of "we don't really need pg_sleep(interval)
> because it's trivial to do yourself" has some merit, and that would be a
> good reason to argue acceptance or not. However, to date that has not
> been the topic of di
On Thu, Oct 17, 2013 at 9:03 AM, Joshua D. Drake wrote:
>
> On 10/17/2013 08:55 AM, Kevin Grittner wrote:
>
>>
>> Robert Haas wrote:
>>
>> I still think my previous proposal of increasing the defaults for
>>> work_mem and maintenance_work_mem by 4X would serve many more
>>> people well than it w
On 10/17/2013 10:01 AM, Robert Haas wrote:
> But if you're asking my opinion, I think doing it on the function
> level is a whole lot better and easier to get right. A flag like the
> one I mentioned here can be set for one particular function with the
> absolute certainty that behavior will not c
On 10/17/2013 09:49 AM, Robert Haas wrote:
A lot. A whole lot, more than what most people have in production with more
than that. You are forgetting a very large segment of the population who
run... VMs.
That's true, but are you actually arguing for keeping work_mem at 1MB?
Even on a VM with
On Thu, Oct 17, 2013 at 12:45 PM, Josh Berkus wrote:
>> Obviously, the implicit casts are not for PostgreSQL and would be
>> rightly rejected here, but I am not sure that the ability to prefer
>> one function or operator over others in an overloading situation is
>> such a bad idea. So far, our i
Fabien,
> My experience at trying to pass minor patches shows that the basic
> behavior is conservatism. Maybe this is necessary to the stability of
> the project, but this is really annoying for pretty small changes on
> side tools, and I think that it tends to over-conservatism and ampers
> good
On Thu, Oct 17, 2013 at 12:03 PM, Joshua D. Drake
wrote:
> On 10/17/2013 08:55 AM, Kevin Grittner wrote:
>> Robert Haas wrote:
>>
>>> I still think my previous proposal of increasing the defaults for
>>> work_mem and maintenance_work_mem by 4X would serve many more
>>> people well than it would
JD,
> A lot. A whole lot, more than what most people have in production with
> more than that. You are forgetting a very large segment of the
> population who run... VMs.
Actually, even a "mini" AWS instance has 1GB of RAM. And nobody who
uses a "micro" is going to expect it to perform well unde
Robert,
> Obviously, the implicit casts are not for PostgreSQL and would be
> rightly rejected here, but I am not sure that the ability to prefer
> one function or operator over others in an overloading situation is
> such a bad idea. So far, our internal testing seems to show that it
> works wel
On Wed, Oct 16, 2013 at 1:25 PM, Stefan Kaltenbrunner
wrote:
> On 10/16/2013 07:04 PM, Robert Haas wrote:
>> On Sat, Oct 12, 2013 at 8:46 PM, Andres Freund
>> wrote:
>>> I think we should remove support the following ports:
>>> - IRIX
>>> - UnixWare
>>> - Tru64
>>
>> According to http://en.wikip
On Thu, Oct 17, 2013 at 08:39:56AM -0400, Robert Haas wrote:
> On Fri, Oct 11, 2013 at 1:14 AM, Noah Misch wrote:
> > On Thu, Oct 10, 2013 at 03:23:30PM +0200, Andres Freund wrote:
> >> On 2013-10-10 08:59:47 -0400, Robert Haas wrote:
> >> > I'd be inclined to make the computation unconditionally
On 10/17/2013 08:55 AM, Kevin Grittner wrote:
Robert Haas wrote:
I still think my previous proposal of increasing the defaults for
work_mem and maintenance_work_mem by 4X would serve many more
people well than it would serve poorly. I haven't heard anyone
disagree with that notion. Does an
Robert Haas wrote:
> I still think my previous proposal of increasing the defaults for
> work_mem and maintenance_work_mem by 4X would serve many more
> people well than it would serve poorly. I haven't heard anyone
> disagree with that notion. Does anyone disagree? Should we do
> it?
I think
Vik Fearing wrote:
> On 09/23/2013 10:51 PM, Alvaro Herrera wrote:
> > + /* are we in the middle of a renegotiation? */
> > + static bool in_ssl_renegotiation = false;
>
> Since this was committed, I'm getting the following warning:
>
> be-secure.c:105:13: warning: ‘in_ssl_renegotiation’ defined
On 10/17/2013 10:23 AM, Alvaro Herrera wrote:
Oskari Saarenmaa wrote:
@@ -1241,8 +1241,8 @@ hstore_to_json_loose(PG_FUNCTION_ARGS)
if (count == 0)
{
- out = palloc(1);
- *out = '\0';
+ out = palloc(3);
+ memcpy(out, "{}", 3
On 17/10/13 17:23, Alvaro Herrera wrote:
Oskari Saarenmaa wrote:
@@ -1241,8 +1241,8 @@ hstore_to_json_loose(PG_FUNCTION_ARGS)
if (count == 0)
{
- out = palloc(1);
- *out = '\0';
+ out = palloc(3);
+ memcpy(out, "{}", 3);
Oskari Saarenmaa wrote:
> @@ -1241,8 +1241,8 @@ hstore_to_json_loose(PG_FUNCTION_ARGS)
>
> if (count == 0)
> {
> - out = palloc(1);
> - *out = '\0';
> + out = palloc(3);
> + memcpy(out, "{}", 3);
> PG_RETURN_TEXT_P(cstring
On 10/17/13 8:06 AM, Robert Haas wrote:
> Actually, this could be fixed by having a way to declare one of the
> overloaded functions as the preferred option and resolving ambiguous
> calls in favor of the highest-priority function. In fact,
> EnterpriseDB has added just such an option to Advanced
On Thu, Oct 17, 2013 at 9:51 AM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>> Actually, this could be fixed by having a way to declare one of the
>> overloaded functions as the preferred option and resolving ambiguous
>> calls in favor of the highest-priority function. In fact,
>> EnterpriseD
Robert Haas escribió:
> Actually, this could be fixed by having a way to declare one of the
> overloaded functions as the preferred option and resolving ambiguous
> calls in favor of the highest-priority function. In fact,
> EnterpriseDB has added just such an option to Advanced Server 9.3, and
>
Hello Vik,
I have attached here an entirely new patch (new documentation and
everything) that should please everyone. It no longer overloads
pg_sleep(double precision) but instead add two new functions:
* pg_sleep_for(interval)
* pg_sleep_until(timestamp with time zone)
Because it's no longe
On 10/17/2013 08:20 AM, Robert Haas wrote:
On Wed, Oct 16, 2013 at 12:02 PM, Oskari Saarenmaa wrote:
hstore_to_json used to return an empty string for empty hstores, but
that is not correct as an empty string is not valid json and calling
row_to_json() on rows which have empty hstores will gen
On 2013-10-17 08:16:58 -0500, Merlin Moncure wrote:
> On Thu, Oct 17, 2013 at 8:01 AM, Andres Freund wrote:
> > Hi,
> >
> > Valgrind tells me:
> > ==442828== Conditional jump or move depends on uninitialised value(s)
> > ==442828==at 0x80084F: record_image_cmp (rowtypes.c:1521)
> > ==442828==
On Thu, Oct 17, 2013 at 7:20 AM, Robert Haas wrote:
> On Wed, Oct 16, 2013 at 12:02 PM, Oskari Saarenmaa wrote:
>> hstore_to_json used to return an empty string for empty hstores, but
>> that is not correct as an empty string is not valid json and calling
>> row_to_json() on rows which have empty
On Thu, Oct 17, 2013 at 8:01 AM, Andres Freund wrote:
> Hi,
>
> Valgrind tells me:
> ==442828== Conditional jump or move depends on uninitialised value(s)
> ==442828==at 0x80084F: record_image_cmp (rowtypes.c:1521)
> ==442828==by 0x801522: btrecordimagecmp (rowtypes.c:1839)
> ==442828==
On 10/17/2013 02:42 PM, Robert Haas wrote:
> On Thu, Oct 17, 2013 at 8:26 AM, Vik Fearing wrote:
>> On 10/17/2013 10:03 AM, Fabien COELHO wrote:
>>> My guess is that it won't be committed if there is a single "but it
>>> might break one code or surprise one user somewhere in the universe",
>>> but
Hi,
Valgrind tells me:
==442828== Conditional jump or move depends on uninitialised value(s)
==442828==at 0x80084F: record_image_cmp (rowtypes.c:1521)
==442828==by 0x801522: btrecordimagecmp (rowtypes.c:1839)
==442828==by 0x8C6604: comparison_shim (sortsupport.c:53)
==442828==by 0x
On Tue, Oct 15, 2013 at 1:19 PM, Peter Geoghegan wrote:
>> There could be
>> other ways of avoiding that problem, though. Here's an example:
>>
>> UPSERT table (keycol1, ..., keycoln) = (keyval1, ..., keyvaln) SET
>> (nonkeycol1, ..., nonkeycoln) = (nonkeyval1, ..., nonkeyvaln)
>>
>> That's prett
On 2013-10-16 09:35:46 -0400, Robert Haas wrote:
> Gah. I fixed one instance of that problem in test_config_settings(),
> but missed the other.
Maybe it'd be better to default to none, just as max_connections
defaults to 1 and shared_buffers to 16? As we write out the value in the
config file, ev
I am new to postgre sql .And i want to add some new feature to postgresql
As a startup i have taken the project to add syntax for table partitioning
CREATE TABLE is modified to accept a PARTITION BY clause. This clause
contains one or more partition declarations. The syntax is as follows:
PARTITI
On 17 Říjen 2013, 5:32, Stephen Frost wrote:
> Alvaro,
>
> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
>> Tomas Vondra wrote:
>> > Attached is the set of flow charts, showing the sequence of callbacks
>> > for all the supported commands (i.e. SELECT, INSERT, UPDATE, DELETE,
>> > ANALYZE). Wo
> What PostgreSQL version is this?
I'm using "Postgresql 9.2.4, compiled by Visual C++ build 1600, 64-bit"
> Are there any triggers on any of these tables?
There are no triggers.
> Any noteworthy extensions installed?
Here is the results returned by "select * from pg_available_extensions"
name
On Tue, Oct 15, 2013 at 9:56 AM, Robert Haas wrote:
> Well, I don't know that any of us can claim to have a lock on what the
> syntax should look like.
Sure. But it's not just syntax. We're talking about functional
differences too, since you're talking about mandating an update, which
is a not th
On Tue, Oct 15, 2013 at 11:34 AM, Peter Geoghegan wrote:
>> Again, other people can have different opinions on this, and that's
>> fine. I'm just giving you mine.
>
> I will defer to the majority opinion here. But you also expressed
> concern about surprising results due to the wrong unique const
On Tue, Oct 15, 2013 at 8:11 AM, Robert Haas wrote:
> I'm not saying "go implement MERGE". I'm saying, make the
> insert-or-update operation a single statement, using some syntax TBD,
> instead of requiring the use of a new insert statement that makes
> invisible rows visible as a side effect, so
On Thu, Oct 17, 2013 at 8:26 AM, Vik Fearing wrote:
> On 10/17/2013 10:03 AM, Fabien COELHO wrote:
>> My guess is that it won't be committed if there is a single "but it
>> might break one code or surprise one user somewhere in the universe",
>> but I wish I'll be proven wrong. IMO, "returned with
On Fri, Oct 11, 2013 at 1:14 AM, Noah Misch wrote:
> On Thu, Oct 10, 2013 at 03:23:30PM +0200, Andres Freund wrote:
>> On 2013-10-10 08:59:47 -0400, Robert Haas wrote:
>> > On Tue, Oct 8, 2013 at 6:24 PM, Andres Freund
>> > wrote:
>> > > Do you have a better alternative? Making the computation u
On 10/17/2013 10:03 AM, Fabien COELHO wrote:
> My guess is that it won't be committed if there is a single "but it
> might break one code or surprise one user somewhere in the universe",
> but I wish I'll be proven wrong. IMO, "returned with feedback" on a 1
> liner is really akin to "rejected".
I
On Wed, Oct 16, 2013 at 5:14 PM, Josh Berkus wrote:
> On 10/16/2013 01:25 PM, Andrew Dunstan wrote:
>> Andres has just been politely pointing out to me that my knowledge of
>> memory allocators is a little out of date (i.e. by a decade or two), and
>> that this memory is not in fact likely to be h
On Wed, Oct 16, 2013 at 12:02 PM, Oskari Saarenmaa wrote:
> hstore_to_json used to return an empty string for empty hstores, but
> that is not correct as an empty string is not valid json and calling
> row_to_json() on rows which have empty hstores will generate invalid
> json for the entire row.
On Wed, Oct 16, 2013 at 8:25 AM, Stéphan BEUZE
wrote:
> The following query is performed concurrently by two threads logged in with
> two different users:
>
> WITH raw_stat AS (
> SELECT
>host(client_addr) as client_addr,
>pid ,
>usename
> FR
On Thu, Oct 17, 2013 at 12:22 AM, Noah Misch wrote:
> Removing support for alpha is a different animal compared to removing support
> for non-gcc MIPS and most of the others in your list. A hacker wishing to
> restore support for another MIPS compiler would fill in the assembly code
> blanks, pro
On Wed, Oct 16, 2013 at 5:16 PM, Peter Eisentraut wrote:
> On 10/16/13 2:40 PM, Robert Haas wrote:
>> On Wed, Oct 16, 2013 at 1:26 PM, Josh Berkus wrote:
>>> Also, as Tom pointed out, at some point we have to either say we really
>>> support overloading or we don't.
>>
>> We clearly do support ov
Hello Vik,
For: Josh, Stephen, me
Against: Robert
Neutral: Tom, you
For the record, I'm not neutral, I'm *FOR*. I reviewed it and said that I
think it is fine. But I'm still nobody here:-)
My experience at trying to pass minor patches shows that the basic
behavior is conservatism. Maybe t
60 matches
Mail list logo
