Hello,
What is the purpose of the [ AND ... ] at the end of the WHEN clause?
Is that for later releases, when presumably additional filter_variables
will be introduced? Right now, if I add AND tag IN ... I get an
ERROR: filter variable tag specified more than once
Joe
--
Sent via
Small release notes correction attached.
Joe
From 330f5af36ffdba8930ea2da8146e8f17e1ec8a68 Mon Sep 17 00:00:00 2001
From: Joe Abbate j...@freedomcircle.com
Date: Fri, 17 May 2013 14:59:03 -0400
Subject: [PATCH] Correct release notes about DROP TABLE IF EXISTS and add
link.
---
doc/src/sgml
Hello hackers,
I've been testing Pyrseas against 9.2rc1. A test that does a CREATE
OPERATOR is giving a small difference. Specifically, the test issues
the statement:
CREATE OPERATOR + (PROCEDURE = upper, RIGHTARG = text);
Pyrseas then queries the pg_operator catalog to map the procedure for
Hello Tom,
On 30/08/12 12:27, Tom Lane wrote:
The reason for the difference is that in 9.2 there's more than one
pg_catalog.upper():
regression=# \df upper
List of functions
Schema | Name | Result data type | Argument data types | Type
Hello Tom,
On 30/08/12 13:23, Tom Lane wrote:
Joe Abbate j...@freedomcircle.com writes:
Hmmm ... Well, I'm just doing the same thing as pg_dump, which in 9.2rc1
still outputs the same as before, namely:
Well, evidently you're *not* doing the same thing as pg_dump.
I meant that the Pyrseas
Hello hackers,
In order to test 9.2rc1, I had to build contrib (because Pyrseas uses
some of those modules). The build instructions
(http://www.postgresql.org/docs/9.2/static/install-procedure.html )
state the way to build everything (contrib + docs, etc.) is
gmake world
Unfortunately, that
Hello Jeff,
On 30/08/12 17:05, Jeff Janes wrote:
I think is probably because you don't have DocBook DTD or some of
the other prerequisites listed in the URL I gave above.
Indeed. I was able to build world after invoking the apt-get line in
J.2.3 on that page. The only adjustment I had to
On 30/08/12 17:36, Tom Lane wrote:
FWIW, that suggests that this version of jade is too old. I'm not sure
that jade per se (as opposed to the successor project openjade) can be
used to build our docs at all --- you should check whether this is
openjade, or really the original project.
It was
On 11/30/2011 09:55 AM, Tom Lane wrote:
One possible solution, if you're getting type information about columns
from the server, is to cast the type OID to regtype and let the regtype
output converter make all the decisions. It's less notation than a join
to pg_type anyway.
Unfortunately,
On 11/30/2011 11:26 AM, Kevin Grittner wrote:
You are prepared to handle the difference between char and char, I
hope.
We have not implemented a type verifier in Pyrseas. It currently
generates SQL based on the type given in the input. In normal usage,
dbtoyaml is expected to be invoked
Hi,
A few months ago, I got an email related to Pyrseas
(http://lists.pgfoundry.org/pipermail/pyrseas-general/2011-August/03.html)
where the user reported he had a table named user and reported a
failure in the dbtoyaml utility. I eventually implemented a simple
quote_id function (only
On 11/29/2011 10:09 PM, Robert Haas wrote:
On Tue, Nov 29, 2011 at 7:29 PM, Joe Abbate j...@freedomcircle.com wrote:
It seems to me that since a TYPE in a column definition or function
argument can be a non-native TYPE, it could be a reserved word and
therefore it should always be allowable
On 11/29/2011 11:41 PM, Tom Lane wrote:
Another way to say that is that the type int4 can be specified in two
ways:
int4(an identifier)
INTEGER (a keyword)
Quoting int4 is no problem, because it's still an identifier, but
quoting integer takes away its
Hi Andrew,
On 10/01/2011 09:46 PM, Andrew Dunstan wrote:
On 10/01/2011 05:48 PM, Joe Abbate wrote:
On 10/01/2011 05:08 PM, Andrew Dunstan wrote:
There is also this gem of behaviour, which is where I started:
p1p2
begin;
drop view foo
On 10/01/2011 05:08 PM, Andrew Dunstan wrote:
While investigating a client problem I just observed that pg_dump takes
a surprisingly large amount of time to dump a schema with a large number
of views. The client's hardware is quite spiffy, and yet pg_dump is
taking many minutes to dump a
On 09/19/2011 09:50 AM, Josh Berkus wrote:
FWIW, the fact that the drafts *are* confidential is symptomatic of
everything which is wrong with the ISO.
Maybe it's time for an open source SQL standard, one not controlled by
the big guys and their IP claims.
Joe
--
Sent via pgsql-hackers
On 09/19/2011 12:40 PM, Christopher Browne wrote:
On Mon, Sep 19, 2011 at 12:20 PM, David Fetter da...@fetter.org wrote:
Actually, I think it *is* a bad idea, as it would require construction
from whole cloth of kinds of mostly political infrastructure that we
don't have, as a community and
Hi Greg,
On 09/19/2011 04:44 PM, Greg Smith wrote:
Not spending as much time sitting in meetings and fighting with other
vendors is one of the competitive advantages PostgreSQL development has
vs. the big guys. There needs to be a pretty serious problem with
your process before adding
Hi,
If a basic operator family is created, e.g.,
create operator family of1 using btree;
shouldn't pg_dump include this in its output? If not, why?
Joe
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 09/07/2011 12:10 PM, Tom Lane wrote:
I guess if it contains no opclasses and no operators either, this code
won't dump it, but isn't it rather useless in such a case?
Yes, I think it's useless, like a book cover without the contents, but
ISTM it should still be dumped (perhaps someone
On 09/04/2011 08:57 AM, Andrew Dunstan wrote:
In what locale does 'sc' sort before 's4'? (And I'd humbly suggest that
whatever locale it is is possibly broken.)
EBCDIC?
Joe
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 08/31/2011 10:17 AM, Tom Lane wrote:
Short of that sort of anal-retentiveness, there are going to be cases
where the dump order is a bit unpredictable. IMO what we need is a
reasonable compromise between verbosity and uniqueness, such that in
normal cases (ie, where you *didn't*
Hi,
In order to compare the schema of two presumably identical databases,
I've been diffing the output of pg_dump -Osx. However, I've found that
the order of the output is not very reliable. For example, after
recreating the Pagila sample database, I find the following:
--- pagila.dmp
Hola Jaime,
On 08/30/2011 03:24 PM, Jaime Casanova wrote:
what about using pg_dump -Fc -Osx and use pg_restore -l to list
objects. then you can sort and compare objects and then a script that
compare schema of objects extracting them with -P, -T or -t
That appears to be of limited use (i.e.,
On 08/30/2011 05:33 PM, Jaime Casanova wrote:
On Tue, Aug 30, 2011 at 3:14 PM, Joe Abbatej...@freedomcircle.com wrote:
Hola Jaime,
On 08/30/2011 03:24 PM, Jaime Casanova wrote:
what about using pg_dump -Fc -Osx and use pg_restore -l to list
objects. then you can sort and compare objects and
On 08/30/2011 06:07 PM, Tom Lane wrote:
Yeah, we've been around on that before. pg_dump does actually sort the
output items (modulo dependency requirements), but it sorts by the same
tag values that are printed by pg_restore -l, and those aren't currently
designed to be unique. It's not too
Hi Stephen,
On 08/30/2011 07:11 PM, Stephen Frost wrote:
* Joe Abbate (j...@freedomcircle.com) wrote:
In order to compare the schema of two presumably identical
databases, I've been diffing the output of pg_dump -Osx.
I'm not sure exactly how it does it, but check_postgres.pl offers
On 08/16/2011 08:52 PM, Tatsuo Ishii wrote:
Presumably it would also need to invalidated if someone did ALTER
TABLE (which might recurse into unspecified children).
Good point. For DROP TABLE/ALTER TABLE, I need to take care of its chidren.
It sort of seems like what you want to do is
On 08/09/2011 01:27 AM, Tom Lane wrote:
Another approach is to check pg_depend. A cast installed by initdb will
match a pin entry in pg_depend (refclassid = pg_cast, refobjid =
cast's OID, deptype = 'p'). You're still out of luck for distinguishing
extension members in existing releases, but
Hi,
I'm trying to query the catalogs to select only the user-defined CASTs
(my test db only has one such CAST). Looking at pg_dump.c, I've come up
with the following so far:
SELECT castsource::regtype AS source,
casttarget::regtype AS target,
castfunc::regprocedure AS
On 08/08/2011 06:31 PM, Joe Abbate wrote:
It seems the only way out is to do something like a 9-way join between
pg_cast, pg_type, pg_proc and pg_namespace to test the source, target
and function namespaces much as dumpCast() does in pg_dump.c. Before I
go that route, I'd thought I'd check
On 06/10/2011 12:02 AM, Tom Lane wrote:
Alex Hunsaker bada...@gmail.com writes:
On Thu, Jun 9, 2011 at 21:05, Tom Lane t...@sss.pgh.pa.us wrote:
In the next couple of days it's going to be time to branch off
REL9_1_STABLE from master, and I realized that I am pretty foggy on
how to do that in
On 06/10/2011 12:40 AM, Tom Lane wrote:
Yes, I was reading exactly that before posting. It talks about pushing
a branch you've created locally, and it talks about what happens when
others pull that down, and it's about as clear as mud w/r/t how the
original pusher sees the remote branch.
On 05/31/2011 04:36 AM, Magnus Hagander wrote:
So in order to start a brand new bikeshed to paint on, have we even
considered a very trivial workflow like letting the bugtracker
actually *only* track our existing lists and archives. That would
mean:
* Mailing lists are *primary*, and the
Hola Alvaro,
On 05/31/2011 11:38 AM, Alvaro Herrera wrote:
I think this would be easier if you crawled the monthly mboxen instead
of the web archives. It'd be preferable to use message-ids to identify
messages rather than year-and-month based URLs.
I can capture the message-ids, as well as
On 05/31/2011 12:41 PM, Kevin Grittner wrote:
The point is that the community seems to have reached a consensus
that they would rather use this URL for the above message:
http://archives.postgresql.org/message-id/20031205173035.ga16...@wolff.to
OK, as I said, I can still capture the
On 05/31/2011 01:13 PM, Magnus Hagander wrote:
Just to be clear, crawling the current archives for this info is
probably the easiest part of the whole project. In fact, the majority
of the information you'd need is *already* in a postgresql database on
search.postgresql.org.
Does that
On 05/30/2011 10:57 AM, Magnus Hagander wrote:
The case I want to avoid is (a). And if it's possible to make (b) just
be the -hackers mailinglist and putting a keyword in the right place,
Did you mean the -bugs mailing list?
On the subject of keywords, considering Robert's suggestion to
Hi Greg,
On 05/29/2011 10:26 PM, Greg Stark wrote:
On Sun, May 29, 2011 at 3:36 PM, Joe Abbate j...@freedomcircle.com wrote:
Anyone interested in the tracker, please visit
http://wiki.postgresql.org/wiki/TrackerDiscussion and add your
feedback/input.
I think this illustrates exactly what
Hi Magnus,
On 05/30/2011 08:45 AM, Magnus Hagander wrote:
It's fine that a bug tracker *tracks* bugs. It should not control
them. That's not how this community currently works, and a lot of
people have said that's how they want it to stay (at least for now).
If I may belabor the point, what
Hi Tom,
On 05/29/2011 11:05 AM, Tom Lane wrote:
In the end, I think that requests for a tracker mostly come from people
who are not part of this community, or at least not part of its mailing
lists (which is about the same thing IMO).
I think that's a bit harsh. I assume you consider GSM a
On 05/29/2011 02:01 PM, Stefan Kaltenbrunner wrote:
feel free to reuse/edit the page as you like it(I have just removed the
notice) - the don't edit thingy was added because people started to
find the page via google (while searching for a tracker/bugreporting
tool) and considered it official
42 matches
Mail list logo
