hat case, since
> there's probably no good way to distinguish it from a query that
> takes a really long time. But if we're going to think about this,
> we might as well think about all the cases.
Well in this case we can still interrupt the query, no? This will drop
us back int
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3),
64-bit
-Ryan Kelly
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index 963f6b4..ba97baf 100644
--- a/src/backend/commands/tablecmds.c
+++ b/src/backend/commands/tablecmds.c
@@ -312,7
hstore
--
"a"=>",b=>1"
[db]> select 'a=>, b=>1'::hstore;
ERROR: Syntax error near 'b' at position 5
LINE 2: select 'a=>, b=>1'::hstore;
In my mind, all of these should have been rejected as erroneous input.
To
> >
>
> Since this is removing a syntax error and not creating one, I'd say it
> should be safe to backpatch.
-Ryan Kelly
diff --git a/contrib/hstore/hstore_io.c b/contrib/hstore/hstore_io.c
index 0eb48cf..f03dcdc 100644
--- a/contrib/hstore/hstore_io.c
+++ b/contrib/h
On Fri, Apr 27, 2012 at 10:22:11AM -0400, Tom Lane wrote:
> Ryan Kelly writes:
> > As long as we make it consistent on both sides of the '=>' (and document
> > it, too), then I don't really care either way. Currently you have to use
> > quotes to get an emp
x27;s apparently easy to create one.
> >
> > I wrote a quick patch to do that, and with the patch the index build
> > finished - but it took hours. And the index was 10GB in size, where the
> > heap is just 12 MB, and searches using the index take ages. Do you have a
> >
older version? It
appears that the version of psql in 9.2 beta 2 does the correct thing,
look at src/bin/psql/describe.c line 142 or so.
>
> Regards. Philippe.
>
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs
-Ryan Kelly
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Tue, Jun 19, 2012 at 07:49:20PM +, j...@tanga.com wrote:
> The following bug has been logged on the website:
>
> Bug reference: 6699
> Logged by: Joe Van Dyk
> Email address: j...@tanga.com
> PostgreSQL version: 9.1.4
> Operating system: OSX
> Description:
>
>
esql.org/docs/9.1/static/indexes.html
http://www.postgresql.org/docs/9.1/static/using-explain.html
>
> Thanks in advance,
>
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pg
o_idx2 ON foo (f1) WHERE id > 10;
>
> COMMENT ON INDEX foo_idx2 IS 'whatever';
>
> create table foo2 (like foo including all);
>
> rollback;
>
>
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
> To make changes to your su
rashes.
>
> regards, tom lane
The latest on this patch can be found here:
http://archives.postgresql.org/message-id/500151c4.5010...@enterprisedb.com
-Ryan Kelly
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ndows 8
> Description:
>
> "pg_dump -Z1 my_db > backup" always make corrupted package.
What does this mean? How did you verify that you got a "corrupted
package"?
> When I try it on postgres database which created from installation: "pg_dump
> pos
ior is but I would think that 'last
> day of a month' + '1 month'::interval would give 'last day of next month'.
>
> I realize on January 29-30th I am not sure what the expected behavior should
> be.
>
'1 month'::interval is the same as '30 days'::interval.
-Ryan Kelly
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Mon, Jan 01/07/13, 2013 at 05:42:40PM +, Daniele Varrazzo wrote:
> On Mon, Jan 7, 2013 at 5:19 PM, Ryan Kelly wrote:
>
> > '1 month'::interval is the same as '30 days'::interval.
>
> No, it's not.
>
> # select '2012-07-31'::
14 matches
Mail list logo
