Jeff Janes wrote:
> On Fri, Jan 2, 2015 at 9:59 PM, Jeff Janes 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 similar missed
call
On Fri, Jan 2, 2015 at 9:59 PM, Jeff Janes wrote:
> On Mon, Dec 29, 2014 at 2:15 PM, Alvaro Herrera
> 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,
On Mon, Dec 29, 2014 at 2:15 PM, Alvaro Herrera
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 to the new object_ad
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
(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 89c8cbed0072ad4d921128b834
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
On 25 December 2014 at 04:47, Tom Lane wrote:
> David Rowley writes:
> > On 25 December 2014 at 00:34, Andres Freund
> 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 w
David Rowley writes:
> On 25 December 2014 at 00:34, Andres Freund 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 be used in case
> someone somewhere
Andres Freund 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 such
warnings anyhow
On 25 December 2014 at 00:34, Andres Freund wrote:
> On 2014-12-24 21:54:20 +1300, David Rowley wrote:
> > On 24 December 2014 at 07:41, Alvaro Herrera
> > wrote:
> >
> > > I have pushed patches 0001 through 0004, with some revisions. Only the
> > > final part is missing.
> > >
> > >
> > Hi Alv
On 2014-12-24 21:54:20 +1300, David Rowley wrote:
> On 24 December 2014 at 07:41, Alvaro Herrera
> 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 fixes a ne
On 24 December 2014 at 07:41, Alvaro Herrera
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 fixes a new compiler
warning that I'm seeing on MSVC.
src\backend\parser\parse_
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 (pgsql-hackers@postgresql.org
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
OB
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 separat
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 Thu, Oct 16, 2014 at 7:01 AM, 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 co
Alvaro,
On Wednesday, October 15, 2014, 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
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 wi
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 ti
On 2014-10-04 21:12:24 -0400, Robert Haas wrote:
> On Fri, Oct 3, 2014 at 4:58 PM, Alvaro Herrera
> 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
Robert Haas wrote:
> On Fri, Oct 3, 2014 at 4:58 PM, Alvaro Herrera
> 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 p
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 n
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.
S
On Mon, Oct 6, 2014 at 7:03 PM, Jim Nasby wrote:
> 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
>
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 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 to
> extract schem
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'
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
con
On Fri, Oct 3, 2014 at 2:33 PM, Alvaro Herrera 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
>> >address_names/address_args
* 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
>
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
> > prec
* 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 c
Stephen Frost wrote:
> Alvaro,
>
> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > + /*
> > +* Make sure that both objname and objargs were passed, or none was.
> > +* Initialize objargs to empty list, which is the most common case.
> > +*/
> > + Assert(PointerIsValid(objnam
Alvaro,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> + /*
> + * Make sure that both objname and objargs were passed, or none was.
> + * Initialize objargs to empty list, which is the most common case.
> + */
> + Assert(PointerIsValid(objname) == PointerIsValid(objarg
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
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?
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:
+
+ address_names
+ text[]
+
+ An array that, together with addre
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:
>
> >+
> >+ address_names
> >+ text[]
> >+
> >+ An array that, together with address_args,
> >+ can be
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 for
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
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
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 dro
>
> > 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 def
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
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 approp
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
Tom Lane wrote:
> Alvaro Herrera 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 b
Alvaro Herrera 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 dropped at the remote
As you probably know, I've studying how to implement a system to allow
replicating DDL commands to remote servers. I have a fairly good grasp
of handling CREATE commands; we have another thread discussing that
involving a JSON output for such commands. That hasn't been carried to
completion yet;
51 matches
Mail list logo
