Jeff Janes wrote:
On Fri, Jan 2, 2015 at 9:59 PM, Jeff Janes jeff.ja...@gmail.com wrote:
This commit 3f88672a4e4d8e648d24ccc65 seems to have broken pg_upgrade for
pg_trgm.
It seems I failed to notice the get_object_address in the ALTER
EXTENSION path. Should be fixed now. I looked for
On Fri, Jan 2, 2015 at 9:59 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Mon, Dec 29, 2014 at 2:15 PM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Here's a patch that tweaks the grammar to use TypeName in COMMENT,
SECURITY LABEL, and DROP for the type and domain cases. The required
On Mon, Dec 29, 2014 at 2:15 PM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Here's a patch that tweaks the grammar to use TypeName in COMMENT,
SECURITY LABEL, and DROP for the type and domain cases. The required
changes in the code are pretty minimal, thankfully. Note the slight
changes
Alvaro Herrera wrote:
Patch 0005 adds getObjectIdentityParts(), which returns the object
identity in arrays that can be passed to pg_get_object_address. This
part needs slight revisions so I'm not sure I will be able to push
tomorrow.
Here's a fresh version of this patch. I chose to add a
(The changes in the regression test are bogus, BTW; I didn't care enough
to get them fixed before sorting out the rest of the mess.)
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training Services
commit
Here's a patch that tweaks the grammar to use TypeName in COMMENT,
SECURITY LABEL, and DROP for the type and domain cases. The required
changes in the code are pretty minimal, thankfully. Note the slight
changes to the new object_address test also.
I think I'm pretty much done with this now, so
On 2014-12-24 21:54:20 +1300, David Rowley wrote:
On 24 December 2014 at 07:41, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
I have pushed patches 0001 through 0004, with some revisions. Only the
final part is missing.
Hi Alvaro,
Would you be able to commit the attached? It just
On 25 December 2014 at 00:34, Andres Freund and...@2ndquadrant.com wrote:
On 2014-12-24 21:54:20 +1300, David Rowley wrote:
On 24 December 2014 at 07:41, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
I have pushed patches 0001 through 0004, with some revisions. Only the
final part
Andres Freund and...@2ndquadrant.com writes:
I really wonder if we can't make msvc reliably recognize this kind of
scenario - especially this case is pretty trivial?
Even if MSVC did understand pg_unreachable(), there would be other
compilers that didn't, so we'd need to worry about suppressing
David Rowley dgrow...@gmail.com writes:
On 25 December 2014 at 00:34, Andres Freund and...@2ndquadrant.com wrote:
I really wonder if we can't make msvc reliably recognize this kind of
scenario - especially this case is pretty trivial?
The attached patch removes the warning, but likely can't
On 25 December 2014 at 04:47, Tom Lane t...@sss.pgh.pa.us wrote:
David Rowley dgrow...@gmail.com writes:
On 25 December 2014 at 00:34, Andres Freund and...@2ndquadrant.com
wrote:
I really wonder if we can't make msvc reliably recognize this kind of
scenario - especially this case is
I have pushed patches 0001 through 0004, with some revisions. Only the
final part is missing.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training Services
--
Sent via pgsql-hackers mailing list
Here's a five-part split of the remaining pieces of this patch.
Patch 0001 is the one I posted in
http://www.postgresql.org/message-id/20141220022308.gy1...@alvh.no-ip.org
which adds support for COMMENT ON CONSTRAINT .. ON DOMAIN. This just
splits OBJECT_CONSTRAINT in OBJECT_TABCONSTRAINT and
Alvaro Herrera wrote:
Alvaro Herrera wrote:
Andres Freund wrote:
Having reread the patch just now I basically see two things to
criticize:
a) why isn't this accessible at SQL level? That seems easy to address.
b) Arguably some of this could well be done in separate commits.
Michael Paquier wrote:
This patch has had no activity for the last two months, is in Needs
Review state and has marked as reviewer Dimitri. As there is no
activity from the reviewer, I am moving that to CF 2014-12 and
removing Dimitri as reviewer. If someone wants to have a look at this
On 2014-10-04 21:12:24 -0400, Robert Haas wrote:
On Fri, Oct 3, 2014 at 4:58 PM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Robert Haas wrote:
I'm not really very convinced that it's a good idea to expose this
instead of just figuring out a way to parse the object identity.
That's
Andres Freund wrote:
Having reread the patch just now I basically see two things to
criticize:
a) why isn't this accessible at SQL level? That seems easy to address.
b) Arguably some of this could well be done in separate commits.
Fair comments. I will split it up.
FWIW, I spent some time
Alvaro Herrera wrote:
Andres Freund wrote:
Having reread the patch just now I basically see two things to
criticize:
a) why isn't this accessible at SQL level? That seems easy to address.
b) Arguably some of this could well be done in separate commits.
Fair comments. I will split it
Robert Haas wrote:
On Fri, Oct 3, 2014 at 4:58 PM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Robert Haas wrote:
I'm not really very convinced that it's a good idea to expose this
instead of just figuring out a way to parse the object identity.
That's the first thing I tried. But
On 10/6/14, 11:24 PM, Robert Haas wrote:
Offlist.
FWIW, I've run into situations more than once in userspace where I need a
way to properly separate schema and object name. Generally I can make do
using reg* casts and then hitting catalog tables, but it'd be nice if there
was an easier way.
Jim Nasby wrote:
On 10/6/14, 11:24 PM, Robert Haas wrote:
Offlist.
FWIW, I've run into situations more than once in userspace where I need a
way to properly separate schema and object name. Generally I can make do
using reg* casts and then hitting catalog tables, but it'd be nice if there
On 10/4/14, 8:12 PM, Robert Haas wrote:
It's just not sane to try to parse such text strings.
But this is a pretty ridiculous argument. We have an existing parser
that does it just fine, and a special-purpose parser that does just
that (and not all of the other stuff that the main parser does)
On Fri, Oct 3, 2014 at 4:58 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Robert Haas wrote:
I'm not really very convinced that it's a good idea to expose this
instead of just figuring out a way to parse the object identity.
That's the first thing I tried. But it's not pretty: you have
On 09/16/2014 09:09 PM, Brightwell, Adam wrote:
I think there's been some changes to this patch since july, care to
resend a new version?
Sure, here it is.
The only difference with the previous version is that it now also
supports column defaults. This was found to be a problem when you
Heikki Linnakangas wrote:
On 09/16/2014 09:09 PM, Brightwell, Adam wrote:
I have given this patch the following review:
- Apply to current master (77e65bf). -- success
- check-world. --success
- multiple FIXME statements still exist -- are there plans to fix these
items? Can the
Alvaro,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
There are three fixmes in the code. One can be handled by just removing
the line; we don't really care about duplicating 10 lines of boilerplate
code. The other two mean missing support for domain constraints and for
default ACLs.
On 10/03/2014 08:08 PM, Stephen Frost wrote:
Alvaro,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
There are three fixmes in the code. One can be handled by just removing
the line; we don't really care about duplicating 10 lines of boilerplate
code. The other two mean missing support
Heikki Linnakangas wrote:
I had a very brief look at the docs, and these extra outputs from
pg_event_trigger_dropped_objects caught my eye:
+row
+ entryliteraladdress_names/literal/entry
+ entrytypetext[]/type/entry
+ entry
+ An array that,
On 10/03/2014 09:06 PM, Alvaro Herrera wrote:
Heikki Linnakangas wrote:
I had a very brief look at the docs, and these extra outputs from
pg_event_trigger_dropped_objects caught my eye:
+row
+ entryliteraladdress_names/literal/entry
+ entrytypetext[]/type/entry
+
Heikki Linnakangas wrote:
On 10/03/2014 09:06 PM, Alvaro Herrera wrote:
Well, the return value from get_object_address is an ObjectAddress.
It's simple enough to create an SQL wrapper that takes the
address_names/address_args arrays and return an ObjectAddress; would
this be useful?
An
Alvaro Herrera wrote:
Precisely the point is not returning those values, because they are
useless to identify the equivalent object in a remote database. What we
need is the object names and other stuff used to uniquely identify it
by user-visible name. We transmit those name arrays to a
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Right. In the add to objname cases, there is already some other
routine that initialized it previously by filling in some stuff; in the
case above, this happens in the getRelationIdentity() immediately
preceding this.
In the other cases we
Stephen Frost wrote:
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Right. In the add to objname cases, there is already some other
routine that initialized it previously by filling in some stuff; in the
case above, this happens in the getRelationIdentity() immediately
preceding
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Stephen Frost wrote:
ahh, ok, that makes a bit more sense, sorry for missing it. Still makes
me wonder why objargs gets special treatment at the top of the function
and objnames doesn't- seems like both should be initialized either
On Fri, Oct 3, 2014 at 2:33 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Heikki Linnakangas wrote:
On 10/03/2014 09:06 PM, Alvaro Herrera wrote:
Well, the return value from get_object_address is an ObjectAddress.
It's simple enough to create an SQL wrapper that takes the
Robert Haas wrote:
I'm not really very convinced that it's a good idea to expose this
instead of just figuring out a way to parse the object identity.
That's the first thing I tried. But it's not pretty: you have to
extract schema names by splitting at a period (and what if a schema name
On 2014-10-03 14:02:09 -0300, Alvaro Herrera wrote:
Since the patch has had good feedback and no further comments arise, I
can just implement support for those two missing object types and push,
and everybody will be happy. Right?
I'd like to see a new version before that out here... I don't
I think there's been some changes to this patch since july, care to
resend a new version?
Sure, here it is.
The only difference with the previous version is that it now also
supports column defaults. This was found to be a problem when you drop
a sequence that some column default
On 2014-06-13 15:50:50 -0400, Alvaro Herrera wrote:
Here's a patch implementing the proposed idea. This is used in the
Bidirectional Replication stuff by Simon/Andres; it works well.
I think there's been some changes to this patch since july, care to
resend a new version?
I think it's
Andres Freund wrote:
On 2014-06-13 15:50:50 -0400, Alvaro Herrera wrote:
Here's a patch implementing the proposed idea. This is used in the
Bidirectional Replication stuff by Simon/Andres; it works well.
I think there's been some changes to this patch since july, care to
resend a new
Hi.
I thought I'd review this patch, since pgaudit uses the
pg_event_trigger_dropped_objects function.
I went through the patch line by line, and I don't really have anything
to say about it. I notice that there are some XXX/FIXME comments in the
code, but it's not clear if those need to (or can
Here's a patch implementing the proposed idea. This is used in the
Bidirectional Replication stuff by Simon/Andres; it works well.
One thing of note is that I added output flags for normal and
original, which mostly come from performDeletion flags. This let one
select only such objects when
Alvaro Herrera alvhe...@2ndquadrant.com writes:
My proposal therefore is to add some more columns to
pg_event_trigger_dropped_objects(): more precisely, objname and objargs,
which would carry exactly what get_object_address() would require to
re-construct an ObjectAddress for the object being
Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
My proposal therefore is to add some more columns to
pg_event_trigger_dropped_objects(): more precisely, objname and objargs,
which would carry exactly what get_object_address() would require to
re-construct an ObjectAddress
44 matches
Mail list logo
