Re: [HACKERS] contrib function naming, and upgrade issues

Why do you need any explicit syntax? If the database is loading an SQL file as a result of a LOAD MODULE command wouldn't it know to set whatever internal state it needs to remember that? -- Greg On 22 Mar 2009, at 23:11, Andrew Gierth wrote: "Tom" == Tom Lane writes: Tom> I doub

Re: [HACKERS] contrib function naming, and upgrade issues

> "Tom" == Tom Lane writes: Tom> I doubt that we want to decorate every CREATE statement we've Tom> got with an optional MODULE clause; to name just one objection, Tom> it'd probably be impossible to do so without making MODULE a Tom> fully reserved word. Tom> What was discussed in the

Re: [HACKERS] contrib function naming, and upgrade issues

> "Dimitri" == Dimitri Fontaine writes: Dimitri> Hi, Dimitri> Heard about http://wiki.postgresql.org/wiki/ExtensionPackaging ? :) Yes, I left a short note on its discussion page a while ago :-) -- Andrew. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make cha

Re: [HACKERS] contrib function naming, and upgrade issues

> "Dimitri" == Dimitri Fontaine writes: >> Partly that's based on the relative inflexibility of the >> search_path setting; it's hard to modify the search_path without >> completely replacing it, so knowledge of the "default" search path >> ends up being propagated to a lot of places. D

Re: [HACKERS] contrib function naming, and upgrade issues

> "Alvaro" == Alvaro Herrera writes: >> I've been thinking about this, and my conclusion is that schemas >> as they currently exist are the wrong tool for making >> modules/packages. Alvaro> This has been discussed at length previously, and we even had Alvaro> an incomplete but substant

Re: [HACKERS] contrib function naming, and upgrade issues

On Sun, Mar 22, 2009 at 10:25 PM, Tom Lane wrote: > Robert Haas writes: >> ...  I suspect that it's going to boil down to running a >> SQL script, which will need to somehow get that module installed.  To >> make that work, I think we need "CREATE MODULE foo" and then "CREATE >> ... MODULE foo".

Re: [HACKERS] contrib function naming, and upgrade issues

Robert Haas writes: > ... I suspect that it's going to boil down to running a > SQL script, which will need to somehow get that module installed. To > make that work, I think we need "CREATE MODULE foo" and then "CREATE > ... MODULE foo". So the SQL script will > create the module and then cre

Re: [HACKERS] contrib function naming, and upgrade issues

On Sun, Mar 22, 2009 at 7:54 AM, Andrew Gierth wrote: >> "Robert" == Robert Haas writes: > >  >> I'm hesitant to do that when we don't yet have either a design or >  >> a migration plan for the module facility.  We might find we'd shot >  >> ourselves in the foot, or at least complicated the

[HACKERS] The BUFFER_HIT and BUFFER_MISS probes seem pretty darn redundant

Whilst cleaning up the dtrace probe documentation, I realized that there is nothing the aforementioned probes tell you that you can't find out (with a lot more data besides) from the final argument of the BUFFER_READ_DONE probe. Furthermore, tallying them as-is would be misleading since you couldn

Re: [HACKERS] Broken stuff in new dtrace probes

Greg Stark writes: > On Wed, Mar 11, 2009 at 11:50 PM, Tom Lane wrote: >> Furthermore, an isExtend call doesn't actually do a read(), so lumping >> them together with regular reads doesn't seem like quite the right thing >> for performance measurement purposes anyway.  Maybe we actually ought to

Re: [HACKERS] contrib function naming, and upgrade issues

On Sun, Mar 22, 2009 at 10:46 PM, Tom Lane wrote: > There might (or might not) be some use-case > for being able to declare that module A depends on module B, Typically, earthdistance requires cube so the module dependency is already something that might be useful. But as you said, it doesn't req

Re: [HACKERS] contrib function naming, and upgrade issues

Dimitri Fontaine writes: > Le 22 mars 09 à 22:05, Tom Lane a écrit : >> This seems drastically overengineered. What do we need two levels of >> objects for? > We need to be able to refer (pg_depend) to (system level) modules. > Any given extension may depend on more than one module. You really

Re: [HACKERS] contrib function naming, and upgrade issues

Le 22 mars 09 à 22:05, Tom Lane a écrit : This seems drastically overengineered. What do we need two levels of objects for? We need to be able to refer (pg_depend) to (system level) modules. Any given extension may depend on more than one module. What did I overlook? -- dim -- Sent via pg

Re: [HACKERS] typedefs for indent

Tom Lane wrote: BTW, is dungbeetle still running Fedora 6? yes. Upgrading it is on my long TODO list. I wish Fedora had a bit longer release cycles. On my F-10 machine the output of objdump seems to be formatted differently than your script is expecting I guess that will make upgr

Re: [HACKERS] contrib function naming, and upgrade issues

Dimitri Fontaine writes: > He also worked out some OS level tools for module handling, but I > think I'd prefer to have another notion in between, the extension. > The extension would be a new SQL object referring to zero, one or more > modules and one or more SQL scripts creating new SQL obj

Re: [HACKERS] typedefs for indent

After doing some further digging I've concluded that the typedefs that are missing from dungbeetle's list are those that are declared, but are never used as the type of anything. For instance AfterTriggerEventDataOneCtid is only used in a sizeof() computation, and there are quite a few enums for w

Re: [HACKERS] contrib function naming, and upgrade issues

Hi, Heard about http://wiki.postgresql.org/wiki/ExtensionPackaging ? :) Le 22 mars 09 à 14:29, Dave Page a écrit : - want to be able to do INSTALL PACKAGE foo; without needing to mess with .sql files. This might default to looking for $libdir/foo.so, or there might be a mechanism to reg

Re: [HACKERS] contrib function naming, and upgrade issues

Hi, Le 22 mars 09 à 12:42, Andrew Gierth a écrit : Tom> I'm hesitant to do that when we don't yet have either a design Tom> or a migration plan for the module facility. We might find we'd Tom> shot ourselves in the foot, or at least complicated the Tom> migration situation unduly. I've been th

Re: [HACKERS] typedefs for indent

Alvaro Herrera writes: > Tom Lane wrote: >> On the other hand, dungbeetle is failing to report >> a whole bunch of typedefs that it should report, > I tend to think that having this list is much better than no list at all > (the current situation), and it's better than the old list we used to > h

Re: [HACKERS] typedefs for indent

Tom Lane wrote: > Andrew Dunstan writes: > > [ typedef lists ] > > Hmm ... the windows members are claiming that "int", "char", "float", > "double" etc are typedefs, which doesn't exactly match up with my > mental model of C. I don't think this is a problem, because the whole point is telling in

Re: [HACKERS] poor wording on SSPI error message

Magnus Hagander writes: > Alvaro Herrera wrote: >>> gettext_noop("could not get security token from context"), r); >> >> looks poorly worded. What "context" is it talking about? Can we be a >> bit more explicit? Any other thoughts on how to improve it? > Hmm. that should probalby read "could

Re: [HACKERS] typedefs for indent

Tom Lane wrote: Andrew Dunstan writes: [ typedef lists ] Hmm ... the windows members are claiming that "int", "char", "float", "double" etc are typedefs, which doesn't exactly match up with my mental model of C. On the other hand, dungbeetle is failing to report a whole bunch of ty

Re: [HACKERS] typedefs for indent

Andrew Dunstan writes: > [ typedef lists ] Hmm ... the windows members are claiming that "int", "char", "float", "double" etc are typedefs, which doesn't exactly match up with my mental model of C. On the other hand, dungbeetle is failing to report a whole bunch of typedefs that it should report

Re: [HACKERS] typedefs for indent

Andrew Dunstan wrote: Tom Lane wrote: Andrew Dunstan writes: Bruce Momjian wrote: I need to run pgindent in a few months. What typedef list am I going to use? This URL gives a typedef list that is (currently) the combine

Re: [HACKERS] typedefs for indent

Tom Lane wrote: Andrew Dunstan writes: Bruce Momjian wrote: I need to run pgindent in a few months. What typedef list am I going to use? This URL gives a typedef list that is (currently) the combined result from three fai

Re: [HACKERS] typedefs for indent

Andrew Dunstan writes: > Bruce Momjian wrote: >> I need to run pgindent in a few months. What typedef list am I going to >> use? > This URL gives a > typedef list that is (currently) the combined result from three fairly > different buildfarm me

Re: [HACKERS] Open 8.4 item list

Bruce Momjian writes: > bruce wrote: >> Here are some of the emails I consider open for 8.4: >> >> http://momjian.us/cgi-bin/pgsql/open > FYI, Tom has added a lot of comments to this page. I have also updated > the HTML because some browsers were not showing the existence of > comments. It wou

Re: [HACKERS] typedefs for indent

Bruce Momjian wrote: Andrew Dunstan wrote: Alvaro Herrera wrote: Andrew Dunstan wrote: OK, I have spent some time generating and filtering typdefs via objdump on various platforms. I filtered them and Bruce's list to eliminate items not actually found in the sources thus

Re: [HACKERS] contrib function naming, and upgrade issues

Dave Page wrote: I think using PACKAGE is a bad idea as it'll confuse people used to Oracle. MODULE perhaps? Right. We debated this extensively in the past. Module was the consensus name. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make ch

Re: [HACKERS] contrib function naming, and upgrade issues

Andrew Gierth wrote: > I've been thinking about this, and my conclusion is that schemas as > they currently exist are the wrong tool for making modules/packages. This has been discussed at length previously, and we even had an incomplete but substantive patch posted. Did you review that? Some o

Re: [HACKERS] contrib function naming, and upgrade issues

On Sun, Mar 22, 2009 at 11:54 AM, Andrew Gierth wrote: >  - want to be able to do  INSTALL PACKAGE foo;  without needing to >   mess with .sql files.  This might default to looking for >   $libdir/foo.so, or there might be a mechanism to register packages >   globally or locally. > >  - want to b

Re: [HACKERS] contrib function naming, and upgrade issues

> "Robert" == Robert Haas writes: >> I'm hesitant to do that when we don't yet have either a design or >> a migration plan for the module facility.  We might find we'd shot >> ourselves in the foot, or at least complicated the migration >> situation unduly. Robert> I think there have be

Re: [HACKERS] contrib function naming, and upgrade issues

> "Tom" == Tom Lane writes: > Robert Treat writes: >> We've been talking about this magical "proper module facility" for >> a few releases now... are we still opposed to putting contrib >> modules in thier own schema? Tom> I'm hesitant to do that when we don't yet have either a design

Re: [HACKERS] contrib function naming, and upgrade issues

> "Tom" == Tom Lane writes: Tom> I agree that this wasn't an amazingly good choice, but I think Tom> there's no real risk of name collisions because fmgr only Tom> searches for such names within the particular .so. >> Oh, if only life were so simple. Tom> I think you are missing the po