Small release notes correction attached.
Joe
>From 330f5af36ffdba8930ea2da8146e8f17e1ec8a68 Mon Sep 17 00:00:00 2001
From: Joe Abbate
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/release-9.3.sgml |
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 pgsql-
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
o
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 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 me
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
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 offi
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
"Asso
Hi Greg,
On 05/29/2011 10:26 PM, Greg Stark wrote:
> On Sun, May 29, 2011 at 3:36 PM, Joe Abbate wrote:
>> Anyone interested in the tracker, please visit
>> http://wiki.postgresql.org/wiki/TrackerDiscussion and add your
>> feedback/input.
>
> I think this illustr
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
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 t
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 mess
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 data
On 06/10/2011 12:02 AM, Tom Lane wrote:
> Alex Hunsaker writes:
>> On Thu, Jun 9, 2011 at 21:05, Tom Lane 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 git. I suppose it's so
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.
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 f
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&#
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
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
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 201
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., i
On 08/30/2011 05:33 PM, Jaime Casanova wrote:
On Tue, Aug 30, 2011 at 3:14 PM, Joe Abbate 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 then a script that
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 c
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 o
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* intentionally
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:
http://www
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:
http://www.postgresql.org/mailpr
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 start
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 mai
On 09/19/2011 12:40 PM, Christopher Browne wrote:
> On Mon, Sep 19, 2011 at 12:20 PM, David Fetter 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 aren't necessar
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 b
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 sc
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:
>>>
>>> p1
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 chec
On 11/29/2011 10:09 PM, Robert Haas wrote:
> On Tue, Nov 29, 2011 at 7:29 PM, Joe Abbate 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 allowa
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 a
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
42 matches
Mail list logo
