Jaime Casanova writes:
> the name). I'm talking about get_ext_ver_list_from_catalog() which is
> a different
> function.
Oh. I see it now. Sorry about that. It's blindly fixed in my git repo
and I'm going to send an updated patch soon now™ which will include the
fix.
Thanks for insisting here…
On Sat, Jul 6, 2013 at 2:25 PM, Dimitri Fontaine wrote:
> Jaime Casanova writes:
>> not sure if you're wrong. but at the very least, you miss a
>> heap_freetuple(oldtup) there, because get_catalog_object_by_oid()
>
> Well, oldtup can be either a syscache copy or a heap tuple. I've been
> looking
Jaime Casanova writes:
> not sure if you're wrong. but at the very least, you miss a
> heap_freetuple(oldtup) there, because get_catalog_object_by_oid()
Well, oldtup can be either a syscache copy or a heap tuple. I've been
looking at other call sites and they don't free their tuple either. So
I'm
On Thu, Jul 4, 2013 at 7:32 AM, Dimitri Fontaine wrote:
>
>> - In alter.c you made AlterObjectRename_internal non static and
>> replaced a SearchSysCache1 call with a get_catalog_object_by_oid one.
>> Now, in its comment that function says that is for simple cases. And
>> because of the things you
Hi,
Please find attached version 8 of the patch, with fixes for almost all
reported problems. Thanks a lot to you reviewers for finding them!
I need some help with:
- toast tables for new catalog tables
- extension.c:1150:25: warning: variable ‘evi’ set but not used
See details below.
Hito
On Thu, Jul 4, 2013 at 12:46 AM, Jaime Casanova wrote:
> On Thu, Jul 4, 2013 at 2:42 AM, Jaime Casanova wrote:
>>
>> create extension test version '123';
>> CREATE EXTENSION
>>
>> postgres=# \df
>>List of functions
>> Schema | Name | Result data type | Argument data types
On Thu, Jul 4, 2013 at 2:42 AM, Jaime Casanova wrote:
>
> create extension test version '123';
> CREATE EXTENSION
>
> postgres=# \df
>List of functions
> Schema | Name | Result data type | Argument data types | Type
> +--+--+
On Mon, Jun 24, 2013 at 6:20 AM, Dimitri Fontaine
wrote:
> Jaime Casanova writes:
>> just tried to build this one, but it doesn't apply cleanly anymore...
>> specially the ColId_or_Sconst contruct in gram.y
>
> Please find attached a new version of the patch, v7, rebased to current
> master tree
I think this is unlikely to work reliably:
+ PG_TRY();
+ {
+ ExtensionControl *control = read_extension_control_file(extname);
+
+ if (control)
+ {
+ ereport(ERROR,
+ (errcode(ERRCODE_DUPLICATE_OBJECT),
+errmsg("extension \"%s\
Very minor comment here: these SGML "id" tags:
+
are pretty important, because they become the URL for the specific page
in the reference docs. So I think you should fix them to be the correct
spelling of the command "alter template for extension", and also perhaps
add an hyphen or two. Maybe
On Thu, Jun 27, 2013 at 5:49 AM, Dimitri Fontaine
wrote:
> I think that's a limitation of the old model and we don't want to turn
> templates for extensions into being shared catalogs. At least that's my
> understanding of the design consensus.
I agree.
--
Robert Haas
EnterpriseDB: http://www.e
Hitoshi Harada writes:
>> > - a template that is created in another template script does not appear
>> to
>> > depend on the parent template.
>>
>> I don't think that should be automatically the case, even if I admit I
>> didn't think about that case.
>>
> Really? My understanding is everything t
On Thu, Jun 27, 2013 at 2:49 AM, Dimitri Fontaine wrote:
> Hi,
>
> Thanks a lot for your review!
>
> Some answers here, new version of the patch with fixes by tuesday.
>
> Hitoshi Harada writes:
> > - create template ex2, create extension ex2, alter template ex2 rename to
> > ex3, create extensio
Hi,
Thanks a lot for your review!
Some answers here, new version of the patch with fixes by tuesday.
Hitoshi Harada writes:
> - If I have control file that has the same name as template, create
> extension picks up control file? Is this by design?
Yes. That should allow to answer most of Heik
On Mon, Jun 24, 2013 at 4:20 AM, Dimitri Fontaine wrote:
> Jaime Casanova writes:
> > just tried to build this one, but it doesn't apply cleanly anymore...
> > specially the ColId_or_Sconst contruct in gram.y
>
> Please find attached a new version of the patch, v7, rebased to current
> master tre
Jaime Casanova writes:
> just tried to build this one, but it doesn't apply cleanly anymore...
> specially the ColId_or_Sconst contruct in gram.y
Please find attached a new version of the patch, v7, rebased to current
master tree and with some more cleanup. I've been using the new grammar
entry N
Jaime Casanova writes:
> just tried to build this one, but it doesn't apply cleanly anymore...
> specially the ColId_or_Sconst contruct in gram.y
Will rebase tomorrow, thanks for the notice!
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent vi
On Wed, Apr 3, 2013 at 8:29 AM, Dimitri Fontaine wrote:
> Hi,
>
> Dimitri Fontaine writes:
>>> Documentation doesn't build, multiple errors. In addition to the reference
>>> pages, there should be a section in the main docs about these templates.
>>
>> I'm now working on that, setting up the docu
Hi,
Dimitri Fontaine writes:
>> Documentation doesn't build, multiple errors. In addition to the reference
>> pages, there should be a section in the main docs about these templates.
>
> I'm now working on that, setting up the documentation tool set.
Fixed in the attached version 6 of the patch.
Heikki Linnakangas writes:
> I'm quite worried about the security ramifications of this patch. Today, if
> you're not sure if a system has e.g sslinfo installed, you can safely just
> run "CREATE EXTENSION sslinfo". With this patch, that's no longer true,
> because "foo" might not be the extension
Hi,
Thanks you for testing and reporting those strange bugs, I should be
able to fix them by Tuesday at the earliest.
Heikki Linnakangas writes:
> create template for extension sslinfo version '1.0' with (schema public) as
> $$ DO EVIL STUFF $$;
What you're saying is that we should restrict the
On Wed, Mar 27, 2013 at 10:32 AM, Alvaro Herrera
wrote:
>> Surely creating an extension template must be a superuser-only
>> operation, in which case this is an issue because Mallory could also
>> have just blown up the world directly if he's already a superuser
>> anyway.
>
> Yeah .. (except "thi
Robert Haas escribió:
> On Wed, Mar 27, 2013 at 10:16 AM, Heikki Linnakangas
> wrote:
> > I'm quite worried about the security ramifications of this patch. Today, if
> > you're not sure if a system has e.g sslinfo installed, you can safely just
> > run "CREATE EXTENSION sslinfo". With this patch,
On 27.03.2013 16:16, Heikki Linnakangas wrote:
Below are some random bugs that I bumped into while testing. These could
be fixed, but frankly I think this should be rejected for security reasons.
Also:
pg_dump does not dump the owner of an extension template correctly.
- Heikki
--
Sent via
On Wed, Mar 27, 2013 at 10:16 AM, Heikki Linnakangas
wrote:
> I'm quite worried about the security ramifications of this patch. Today, if
> you're not sure if a system has e.g sslinfo installed, you can safely just
> run "CREATE EXTENSION sslinfo". With this patch, that's no longer true,
> because
On 15.03.2013 23:00, Alvaro Herrera wrote:
Dimitri Fontaine wrote:
Please find attached v3 of the Extension Templates patch, with full
pg_dump support thanks to having merged default_full_version, appended
with some regression tests now that it's possible.
Here's a rebased version; there were
Alvaro Herrera writes:
> Here's a rebased version; there were some merge conflicts with master.
Thanks!
> I also fixed some compiler warnings. I haven't reviewed the patch in
> any detail yet. One thing that jump at me from the code style
> perspective is the strange way it deals with "isnull"
Tom Lane writes:
> Um ... what's with those hstore changes?
Just showing how we could deal with shipping 1.1 in the future, it's not
meant to be applied as-is. Part of the feature set in there comes from
when Robert complained that we can't have
CREATE EXTENSION hstore;
install version 1.1 fr
Alvaro Herrera writes:
> Here's a rebased version; there were some merge conflicts with master.
Um ... what's with those hstore changes?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http:/
On 2013-03-04 11:51:36 +0100, Dimitri Fontaine wrote:
> - Assert() HeapTuple's catalog
>
> In the function extract_ctlversion() I would like to be able to
> Assert() that the given tuple is from the right catalog and didn't
> see how to do that
->t_tableOid. Haven't read the patch,
Craig Ringer writes:
> There hasn't been visible movement on this work since the 22'nd when you
> posted v3 and it was flagged for further review. Nobody's stepped up,
> can we get any interest in this?
I hope we can, it's a pretty important development as far as I'm
concerned, a building block f
On 02/23/2013 12:03 AM, Dimitri Fontaine wrote:
> Hi,
>
> Please find attached v3 of the Extension Templates patch, with full
> pg_dump support thanks to having merged default_full_version, appended
> with some regression tests now that it's possible.
There hasn't been visible movement on this wor
Hi,
Please find attached v3 of the Extension Templates patch, with full
pg_dump support thanks to having merged default_full_version, appended
with some regression tests now that it's possible.
The patch also implements ALTER RENAME and OWNER facilities for those
new templates objects.
Dimitri F
Hi,
Please find attached v2 of the Extension Templates patch, with pg_dump
support and assorted fixes. It's still missing ALTER RENAME and OWNER
facilities, and owner in the dump. There's a design point I want to
address with some input before getting there, though. Hence this email.
Dimitri Font
Dimitri Fontaine writes:
> Now that I've written this in that email, I think I'm going to go for
> the new command. But maybe we have some precedent for objects that we
> list in pg_dump only for solving several steps dependency lookups?
Yes, pg_dump has lots of objects that might not appear in a
Dimitri Fontaine writes:
> Please find attached a new version of the patch, answering to most of
> your reviewing points. I'll post another version shortly with support
> for pg_dump and alter owner/rename.
So, as far as pg_dump is concerned, I have a trick question here.
We now have those new c
Hi,
Please find attached a new version of the patch, answering to most of
your reviewing points. I'll post another version shortly with support
for pg_dump and alter owner/rename.
The main priority was to confirm that the implementation is conforming
to the rought specs and design we agreed befor
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> Tom Lane writes:
> > We already do: see text search templates. The code tends to call those
> > TSTEMPLATEs, so I'd suggest ACL_KIND_EXTTEMPLATE or some such. I agree
> > with Stephen's objection to use of the bare word "template".
>
> Yes, m
Tom Lane writes:
> We already do: see text search templates. The code tends to call those
> TSTEMPLATEs, so I'd suggest ACL_KIND_EXTTEMPLATE or some such. I agree
> with Stephen's objection to use of the bare word "template".
Yes, me too, but I had a hard time to convince myself of using such a
Stephen Frost writes:
> 'Extension Template' is fine, I was just objecting to places in the code
> where it just says 'TEMPLATE'. I imagine we might have some 'XXX
> Template' at some point in the future and then we'd have confusion
> between "is this an *extension* template or an XXX template?".
* Andres Freund (and...@2ndquadrant.com) wrote:
> On 2013-01-18 12:45:02 -0500, Stephen Frost wrote:
> > 'Template' seems like a really broad term which might end up being
> > associated with things beyond extensions, yet there are a number of
> > places where you just use 'TEMPLATE', eg, ACL_KIND_
On 2013-01-18 12:45:02 -0500, Stephen Frost wrote:
> * Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> > Please find attached a preliminary patch following the TEMPLATE ideas,
> > and thanks in particular to Tom and Heikki for a practical design about
> > how to solve that problem!
>
> Given th
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> Please find attached a preliminary patch following the TEMPLATE ideas,
> and thanks in particular to Tom and Heikki for a practical design about
> how to solve that problem!
Given that it's preliminary and v0 and big and whatnot, it seems like
i
Dimitri Fontaine writes:
> Please find attached a preliminary patch following the TEMPLATE ideas,
FYI, I've added it to the commitfest:
https://commitfest.postgresql.org/action/patch_view?id=1032
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Supp
Hi,
Please find attached a preliminary patch following the TEMPLATE ideas,
and thanks in particular to Tom and Heikki for a practical design about
how to solve that problem!
Tom Lane writes:
>> - Extension Scripts are now stored in the catalogs, right?
>
> Only for these new-style thingies. I
Tom Lane writes:
> Only for these new-style thingies. I am not suggesting breaking the
> existing file-based implementation, only offering a parallel
> catalog-based implementation too. We'd have to think about what to do
> for name collisions --- probably having the catalog entry take
> precede
Dimitri Fontaine writes:
> Tom Lane writes:
>> I think a separate kind of "extension template" object would make a lot
>> more sense.
> I'm on board now. We still have some questions to answer, and here's a
> worked out design proposal for implementing my understanding of your
> "extension's tem
Tom Lane writes:
>> CREATE TEMPLATE yadda;
>> ALTER TEMPLATE yadda ADD FILE 'yadda--1.0.sql' CONTENT $$...$$;
>
> FWIW, the more I think about it the more I like the notion of treating
> "extension templates" as a separate kind of object. I do see value in
> storing them inside the database syste
48 matches
Mail list logo
