Robert Haas writes:
> I have committed the cfparser patch to which the above comments refer.
Excellent, thank you! On to merging that into the extension's main
branch, will still wait until after pg_execute_sql_file() is in to
produce extension.v15.patch, unless advised otherwise.
Regards,
--
D
On Thu, Nov 25, 2010 at 4:06 PM, Dimitri Fontaine
wrote:
> Itagaki Takahiro writes:
>> Thanks. I'll move the patch to Ready for Committer.
>
> Thanks!
I have committed the cfparser patch to which the above comments refer.
One patch per thread makes things easier!
I adopted most of Itagaki Taka
Itagaki Takahiro writes:
> Thanks. I'll move the patch to Ready for Committer.
Thanks!
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://w
On Thu, Nov 25, 2010 at 05:02, Dimitri Fontaine wrote:
> Something like the attached, version 5 of the patch? I've been using the
> function name ParseConfigFp because the internal parameter was called fp
> in the previous function body. I suppose that could easily be changed at
> commit time if n
Itagaki Takahiro writes:
> RECOVERY_COMMAND_FILE is opened twice in the patch. The first time
> is for checking the existence, and the second time is for parsing.
> Instead of the repeat, how about adding FILE* version of parser?
> It will be also called from ParseConfigFile() as a sub routine.
>
On Tue, Nov 23, 2010 at 18:19, Dimitri Fontaine wrote:
> Please find that done in attached v4 of the cfparser patch.
RECOVERY_COMMAND_FILE is opened twice in the patch. The first time
is for checking the existence, and the second time is for parsing.
Instead of the repeat, how about adding FILE*
On 22.11.2010 03:35, Robert Haas wrote:
On Sun, Nov 21, 2010 at 8:10 PM, Itagaki Takahiro
wrote:
On Wed, Oct 20, 2010 at 01:36, Dimitri Fontaine wrote:
Ah yes, thinking it's an easy patch is not helping. Please find attached
a revised version of it.
I checked cfparser.v2.patch.
It exports
Alvaro Herrera writes:
> the handling of relative vs absolute paths is bogus here. I think it'd
> make more sense to have a bool "are we including"; and if that's false and
> the path is not absolute, then the file is relative to CWD; or maybe we
> make it absolute by prepending PGDATA; maybe som
Alvaro Herrera writes:
> Hmm, the first thought that comes to mind is that the GucContext param
> to ParseConfigFile is unused and can be removed. This is probably an
> oversight from when include files were introduced in 2006.
Thanks for caring about that part.
> I don't like the fact that thi
Excerpts from Dimitri Fontaine's message of lun nov 22 18:12:39 -0300 2010:
> Itagaki Takahiro writes:
> > No. My suggestion was just to use the internal parser.
>
> What about something like the attached, cfparser.v3.patch?
the handling of relative vs absolute paths is bogus here. I think it'd
Excerpts from Alvaro Herrera's message of lun nov 22 18:59:52 -0300 2010:
> Hmm, the first thought that comes to mind is that the GucContext param
> to ParseConfigFile is unused and can be removed. This is probably an
> oversight from when include files were introduced in 2006.
Committed and pus
Excerpts from Dimitri Fontaine's message of lun nov 22 18:12:39 -0300 2010:
> Itagaki Takahiro writes:
> > No. My suggestion was just to use the internal parser.
>
> What about something like the attached, cfparser.v3.patch?
>
> If that looks ok, do we want to add some documentation about the ne
Itagaki Takahiro writes:
> No. My suggestion was just to use the internal parser.
What about something like the attached, cfparser.v3.patch?
If that looks ok, do we want to add some documentation about the new
lexer capabilities? Also, for what good reason would we want to prevent
people from us
On Mon, Nov 22, 2010 at 18:36, Dimitri Fontaine wrote:
>> * Can we export ParseConfigFile() in guc-file.l rather than
>> parseRecoveryCommandFileLine()?
>
> Should we then consider recovery.conf entries as ordinary GUCs? That
> would allow to connect to a standby and issue 'show primary_conninf
Itagaki Takahiro writes:
> I checked cfparser.v2.patch.
Thanks for reviewing it!
> It exports the static parseRecoveryCommandFileLine() in xlog.c
> as the global cfParseOneLine() in cfparser.c without modification.
>
> It generates one warning, but it can be easily fixed.
> cfparser.c:34: warn
On Sun, Nov 21, 2010 at 8:10 PM, Itagaki Takahiro
wrote:
> On Wed, Oct 20, 2010 at 01:36, Dimitri Fontaine
> wrote:
>> Ah yes, thinking it's an easy patch is not helping. Please find attached
>> a revised version of it.
>
> I checked cfparser.v2.patch.
>
> It exports the static parseRecoveryComm
On Wed, Oct 20, 2010 at 01:36, Dimitri Fontaine wrote:
> Ah yes, thinking it's an easy patch is not helping. Please find attached
> a revised version of it.
I checked cfparser.v2.patch.
It exports the static parseRecoveryCommandFileLine() in xlog.c
as the global cfParseOneLine() in cfparser.c wi
Le 25 oct. 2010 à 17:26, Alvaro Herrera a écrit :
> Ah, some reading of the patch reveals that the "script" defaults to the
> control file name, but it can be overridden.
Yes, that's new in v10. In v11 I've kept that and removed the name property in
the control file, so that we have:
cat contri
Le 25 oct. 2010 à 17:26, Alvaro Herrera a écrit :
> Ah, some reading of the patch reveals that the "script" defaults to the
> control file name, but it can be overridden.
Yes, that's new in v10. In v11 I've kept that and removed the name property in
the control file, so that we have:
cat contri
Excerpts from Dimitri Fontaine's message of vie oct 22 16:43:56 -0300 2010:
> Dimitri Fontaine writes:
> > For information, when we talk about performance problem, please note
> > that on my workstation with a default setup (not that it's important
> > here) we're talking about 86,420 ms for a loo
Excerpts from Alvaro Herrera's message of lun oct 25 10:37:22 -0300 2010:
> Excerpts from Alvaro Herrera's message of vie oct 22 17:02:22 -0300 2010:
>
> > > I'll go rework the patch sometime later to drop the name from the
> > > control file, but that also means fixing several contrib modules by
Excerpts from Alvaro Herrera's message of vie oct 22 17:02:22 -0300 2010:
> Excerpts from Dimitri Fontaine's message of vie oct 22 16:21:14 -0300 2010:
> > I'll go rework the patch sometime later to drop the name from the
> > control file, but that also means fixing several contrib modules by
> >
Itagaki Takahiro writes:
> On Sat, Oct 23, 2010 at 5:26 AM, Josh Berkus wrote:
>>> Yeah - what is the feasibility of cleaning up the things where there
>>> are naming inconsistencies right now?
>>
>> Easy. Â Heck, the only reason we didn't do it 2 years ago was that we
>> were waiting for extens
On Sat, Oct 23, 2010 at 5:26 AM, Josh Berkus wrote:
>> Yeah - what is the feasibility of cleaning up the things where there
>> are naming inconsistencies right now?
>
> Easy. Heck, the only reason we didn't do it 2 years ago was that we
> were waiting for extensions before bothering.
We could re
Dimitri Fontaine writes:
> Anyway, my point is that by default there's no directory scanning: the
> lookup is first directed towards ${extension-name}.control, of
> course. Only when this file does not exists or its name property is
> different from the extension name do we get to scan the directo
> Yeah - what is the feasibility of cleaning up the things where there
> are naming inconsistencies right now?
Easy. Heck, the only reason we didn't do it 2 years ago was that we
were waiting for extensions before bothering.
Go Dimitri! Yaaay.
--
-- Josh Ber
Excerpts from Robert Haas's message of vie oct 22 17:07:10 -0300 2010:
> On Fri, Oct 22, 2010 at 4:02 PM, Alvaro Herrera
> wrote:
> > That said, I don't think there's any reason now to stop a committer from
> > renaming files (as long as this has been previously discussed and agreed
> > to, just l
On Fri, Oct 22, 2010 at 4:02 PM, Alvaro Herrera
wrote:
> That said, I don't think there's any reason now to stop a committer from
> renaming files (as long as this has been previously discussed and agreed
> to, just like any other commit).
Yeah - what is the feasibility of cleaning up the things
Excerpts from Dimitri Fontaine's message of vie oct 22 16:21:14 -0300 2010:
> So I think it's a good compromise, and as it's superuser-only I would
> think it's acceptable as-is. Apparently it's not, which ain't the end of
> the world but an unexpected surprise for me. And when I don't
> understan
Dimitri Fontaine writes:
> For information, when we talk about performance problem, please note
> that on my workstation with a default setup (not that it's important
> here) we're talking about 86,420 ms for a loop of 100
> perform * from pg_extensions;
That's right, but
> That displays 36 ex
Alvaro Herrera writes:
> Well, things like pgfoundry project names are also restricted AFAICT and
> I don't think anyone has a problem with that.
For things you publish, sure. But extensions will also handle in-house
developments of functions and other in-database API-like stuff, in fact
any SQL
Excerpts from Dimitri Fontaine's message of vie oct 22 13:30:22 -0300 2010:
> So extension names are forced into English? I would live with that, I
> just don't find the answer friendly to the users.
Well, things like pgfoundry project names are also restricted AFAICT and
I don't think anyone has
Andrew Dunstan writes:
> ASCII is not the same thing as English. You can create the names in Pig
> Latin or Redneck if you want. It's the charset that's being restricted here,
> and we restrict many more things than this to ASCII.
I'd like to read Itagaki's opinion here, will wait :)
--
Dimitri
On 10/22/2010 12:30 PM, Dimitri Fontaine wrote:
Alvaro Herrera writes:
Excerpts from Dimitri Fontaine's message of vie oct 22 12:25:07 -0300 2010:
Now, if we want to do it the other way round and force extension name to
be the filename, we will have to live with all the restrictions that
fi
Alvaro Herrera writes:
> Excerpts from Dimitri Fontaine's message of vie oct 22 12:25:07 -0300 2010:
>
>> Now, if we want to do it the other way round and force extension name to
>> be the filename, we will have to live with all the restrictions that
>> filename imposes and that are not the same d
Excerpts from Alvaro Herrera's message of vie oct 22 13:17:41 -0300 2010:
> > Given that the control file now supports an encoding parameter, I don't
> > see what this is good for, but I might be missing something obvious for
> > people working with different encodings etc. Japan seems to be quite
Excerpts from Dimitri Fontaine's message of vie oct 22 12:25:07 -0300 2010:
> Now, if we want to do it the other way round and force extension name to
> be the filename, we will have to live with all the restrictions that
> filename imposes and that are not the same depending on the OS and the
> f
Tom Lane writes:
> Yes. It's horrid for performance, and it's worse for understandability,
> and there's no obvious benefit to set against those. Please let's make
> the rule that the control file name equals the extension name.
Performance… well if you say that CREATE EXTENSION performance pre
Alvaro Herrera writes:
>> Fixed by having the CREATE EXTENSION command consider it's being given
>> the name of the extension as found in the control file, rather than the
>> control file base name.
>
> Hang on. Did I miss something? Why doesn't the control file name equal
> the extension name?
Alvaro Herrera writes:
> Hang on. Did I miss something? Why doesn't the control file name equal
> the extension name? I think the idea that you have to scan the whole
> share directory and parse all control files to find the one you need is
> a bit strange.
Yes. It's horrid for performance, a
Excerpts from Dimitri Fontaine's message of vie oct 22 10:43:58 -0300 2010:
> Itagaki Takahiro writes:
> > * There are some inconsistency between extension names in \dx+ view
> > and actual name used by CREATE EXTENSION.
> > - auto_username => insert_username
> > - intarray => _int
> > - xm
Itagaki Takahiro writes:
> BTW, did you register your patch to the next commitfest?
> It would be better to do so for tracking the activities.
> https://commitfest.postgresql.org/action/commitfest_view?id=8
https://commitfest.postgresql.org/action/patch_view?id=404
--
Dimitri Fontaine
http://2n
Dimitri Fontaine writes:
> That's done now and for those paying attention, of course those examples
> won't need to add a script property in their control files, as soon as
> we both scan the SHAREDIR to find the proper control file and that the
> default script is ${name}.sql, which is what's use
Dimitri Fontaine writes:
> I lean toward adding support for a script variable into the control file
> which defaults to script = '${name}.sql' and will have to be edited only
> in those 3 cases you're reporting about. I'm going to work on that this
> morning, it looks simple enough to get reworked
On Fri, Oct 22, 2010 at 1:31 AM, Dimitri Fontaine
wrote:
> Of course, you what that means? Yes, another version of the patch, that
> will build the control file out of the control.in at build time rather
> than install time, and that's back to using EXTVERSION both in the
> Makefile and in the .co
On Thu, Oct 21, 2010 at 11:12 AM, Dimitri Fontaine
wrote:
> "David E. Wheeler" writes:
>> Sure. The reason to do it, though, is so that extension authors can create
>> just one metadata file, instead of two (or three, if one must also put such
>> data into the Makefile).
>
> That's a good idea, b
Excerpts from Dimitri Fontaine's message of jue oct 21 12:53:18 -0300 2010:
> This part of the problem didn't receive much thoughts yet, and it shows
> up. About the rest of the patch have been in my head for months, I
> expect less problems there...
Keep on it. You're doing a terrific job.
--
"David E. Wheeler" writes:
> Be aware that PGXS sets a $(VERSION) variable already, so you'll need
> to use another name, I think, to guard from conflicts. This is in
> Makefile.global:
Of course that's not a problem for contribs, and I used EXTVERSION in a
previous version of the patch. I guess
On Oct 21, 2010, at 8:12 AM, Dimitri Fontaine wrote:
> That's a good idea, but my guess is that the implementation cost of
> supporting the control format in your perl infrastructure is at least an
> order of magnitude lower than the cost for me to support your current
> JSON file format, so I lea
"David E. Wheeler" writes:
> Sure. The reason to do it, though, is so that extension authors can create
> just one metadata file, instead of two (or three, if one must also put such
> data into the Makefile).
That's a good idea, but my guess is that the implementation cost of
supporting the contr
On Oct 21, 2010, at 12:33 AM, Dimitri Fontaine wrote:
> I don't see what it buys us in this very context. The main thing here to
> realize is that I wrote about no code to parse the control file. I don't
> think the extension patch should depend on the JSON-in-core patch.
>
> Now, once we have JS
Tom Lane writes:
> ... well, that's just a bug in hstore. *All* the contrib modules
> should be using PGXS, unless they have a damn good reason not to;
> which is not apparent for hstore.
Here's a patch.
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Dimitri Fontaine writes:
> Itagaki Takahiro writes:
>> Why does only hstore have version '9.1'? Any other modules have
>> '9.1devel'.
> It's the only contrib that's not using PGXS but instead directly
> includes $(top_builddir)/src/Makefile.global,
... well, that's just a bug in hstore. *All*
"David E. Wheeler" writes:
> Might I suggest instead a META.json file like PGXN requires? Here's a
> simple example:
I don't see what it buys us in this very context. The main thing here to
realize is that I wrote about no code to parse the control file. I don't
think the extension patch should d
On Oct 20, 2010, at 9:58 PM, Alvaro Herrera wrote:
> What's wrong with sticking to Makefile syntax? Are we intending to
> build a JSON parser in GNU make perchance?
That metadata isn't *for* make, is it?
D
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
Excerpts from Itagaki Takahiro's message of jue oct 21 00:01:59 -0300 2010:
> On Thu, Oct 21, 2010 at 8:14 AM, David E. Wheeler
> wrote:
> > Might I suggest instead a META.json file like PGXN requires?
>
> I think JSON is also reasonable, but one of the problem to use JSON format is
> we cannot
On Thu, Oct 21, 2010 at 8:14 AM, David E. Wheeler wrote:
> Might I suggest instead a META.json file like PGXN requires?
I think JSON is also reasonable, but one of the problem to use JSON format is
we cannot apply the extension patch until JSON patch has been applied ;-)
BTW, does anyone needs J
On Thu, Oct 21, 2010 at 7:12 AM, Dimitri Fontaine
wrote:
> This control file contains at minimum a single line for the name of the
> extension, but it's better already with a comment for users. I've been
> filling them for our extensions, pasting from the documentation:
>
> name | v
On Oct 20, 2010, at 3:12 PM, Dimitri Fontaine wrote:
> So, the idea is that $(EXTENSION) is a list of extensions you're
> providing from the Makefile (most often, a list of one extension, but
> contrib/spi is an exception here). Each extension in the list must have
> a corresponding $EXTENSION.con
Tom Lane writes:
> That is simply a horrid idea. Just make it specify EXTENSION.
And VERSION too, finally.
So any extension
>
>> and guessing
>> the CONTROL file name from the EXTENSION name only occurs when CONTROL
>> has not been provided.
>
> Here, on the other hand, I'm wondering why have
Tom Lane writes:
> That is simply a horrid idea. Just make it specify EXTENSION.
Black magic it is, will remove in v7.
> Is there any sane use-case for the control file to not be named the same
> as the extension? It seems like that would accomplish little except to
> sow confusion.
The goal
Dimitri Fontaine writes:
> Tom Lane writes:
>> I don't think that "no changes to the makefiles" is a requirement,
>> or even a wish-list item, for this. I think it's perfectly reasonable
>> for the makefile to have to specify the module name; far better that
>> than that we get the name by some
Tom Lane writes:
>> and use the equivalent of SET LOCAL in the CREATE EXTENSION code?
>
> I had assumed that that was how he was doing it ...
I'm currently doing:
SetConfigOption("client_min_messages", "warning", PGC_SUSET,
PGC_S_SESSION);
And then manually reverting to what was there b
Tom Lane writes:
> I don't think that "no changes to the makefiles" is a requirement,
> or even a wish-list item, for this. I think it's perfectly reasonable
> for the makefile to have to specify the module name; far better that
> than that we get the name by some "magic" or other.
It seemed eas
Alvaro Herrera writes:
> Excerpts from Dimitri Fontaine's message of mié oct 20 07:22:53 -0300 2010:
>> Using SPI to execute the extension's script already means that it can
>> not contain explicit BEGIN and COMMIT commands. Now, is it possible to
>> force a Reset of all GUCs after script's execu
Dimitri Fontaine writes:
> Tom Lane writes:
>> If the extensions manager is dependent on the assumption that a module's
>> name matches the name of the directory it's built in
> It is not. There's some magic for simple cases so that contrib mostly
> "works" with no editing, but of course, that's
Excerpts from Dimitri Fontaine's message of mié oct 20 07:22:53 -0300 2010:
> Itagaki Takahiro writes:
> > CREATE EXTENSION command
> > * Environment could be modified by the installer script.
> > =# SHOW search_path; => "$user",public
> > =# CREATE EXTENSION dblink;
> > =# SHOW search_
Robert Haas writes:
> On Wed, Oct 20, 2010 at 6:22 AM, Dimitri Fontaine
> wrote:
>> In v6 patch, should client_min_messages or log_min_messages be lower
>> than WARNING, they get set to WARNING for the script install context. We
>> still dump the extension's script at each WARNING, but you can se
Tom Lane writes:
> If the extensions manager is dependent on the assumption that a module's
> name matches the name of the directory it's built in
It is not. There's some magic for simple cases so that contrib mostly
"works" with no editing, but of course, that's only mostly.
The version Itakagi
Itagaki Takahiro writes:
> On Wed, Oct 20, 2010 at 12:58 PM, Alvaro Herrera
> wrote:
>> Lets rename the directory.
> Hmmm, but we call it 'xml2' in the doc. There is no 'pgxml' at all in it.
> http://developer.postgresql.org/pgdocs/postgres/xml2.html
> However, I don't think we can change the m
On Wed, Oct 20, 2010 at 9:33 AM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> I would vote for overriding client_min_messages but not log_min_messages.
>
> Well it defaults to WARNING so I see your point. Then again, we're
> talking about hundreds of lines (3197 lines of isn, 531 lines for
>
Robert Haas writes:
> I would vote for overriding client_min_messages but not log_min_messages.
Well it defaults to WARNING so I see your point. Then again, we're
talking about hundreds of lines (3197 lines of isn, 531 lines for
hstore) of output per message, containing a script that you're not
m
On Wed, Oct 20, 2010 at 6:22 AM, Dimitri Fontaine
wrote:
> In v6 patch, should client_min_messages or log_min_messages be lower
> than WARNING, they get set to WARNING for the script install context. We
> still dump the extension's script at each WARNING, but you can set your
> client_min_messages
Tom Lane writes:
> Robert Haas writes:
>> It seems good to do this in the normal case, but (1) if
>> client_min_messages was already set higher than WARNING, we probably
>> should not lower it and (2) we might want to have a way to lower it
>> for troubleshooting purposes.
>
> I think the standar
Sorry. I missed v5 patch and other new ones.
Some of the issues might have been already fixed in the new version.
On Wed, Oct 20, 2010 at 12:19 PM, Itagaki Takahiro
wrote:
> On Tue, Oct 19, 2010 at 9:33 PM, Dimitri Fontaine
>> Fixed in v4, attached.
>
> Source code
> * It still has a wa
On Wed, Oct 20, 2010 at 12:58 PM, Alvaro Herrera
wrote:
>> * xml2 module has a different extension name from the directory name.
>> The directory name is 'xml2', but the extension name is 'pgxml'.
>
> Lets rename the directory.
Hmmm, but we call it 'xml2' in the doc. There is no 'pgxml' at all in
Excerpts from Itagaki Takahiro's message of mié oct 20 00:19:44 -0300 2010:
> * xml2 module has a different extension name from the directory name.
> The directory name is 'xml2', but the extension name is 'pgxml'.
> I'm not sure whether we should change the names. Or, merging xml2 module
> into c
On Tue, Oct 19, 2010 at 9:33 PM, Dimitri Fontaine
wrote:
> Fixed in v4, attached.
It works as expected in basic functionality, so I pick up edge case issues.
Some of them might be a problem for the patch; They might come from our
non-standardized module design.
Source code
* It still h
Excerpts from Dimitri Fontaine's message of mar oct 19 13:09:47 -0300 2010:
> Tom Lane writes:
> > You could argue that either way I guess. The script knows what it
> > needs, but OTOH just about every extension there is will probably
> > be generating useless NOTICEs unless something is done, so
Robert Haas writes:
> On Tue, Oct 19, 2010 at 12:09 PM, Dimitri Fontaine
> wrote:
>> Either way is the key here too, so please find attached a revised (v5)
>> patch which will force log_min_messages and client_min_messages to
>> WARNING while the script is run.
> It seems good to do this in the
On Tue, Oct 19, 2010 at 12:09 PM, Dimitri Fontaine
wrote:
> Tom Lane writes:
>> You could argue that either way I guess. The script knows what it
>> needs, but OTOH just about every extension there is will probably
>> be generating useless NOTICEs unless something is done, so maybe
>> the extens
Alvaro Herrera writes:
> Hmm, this needs some cleanup; the comments still talk about the old
> function name; and about just the recovery.conf file.
Ah yes, thinking it's an easy patch is not helping. Please find attached
a revised version of it.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.
Alvaro Herrera writes:
> The error message wording needs some work; maybe
> errmsg("file \"%s\" could not be executed", filename)
[...]
> I happened to notice that there are several pieces of code that are
> calling SPI_connect and SPI_finish without checking the return value,
> notably the
Excerpts from Dimitri Fontaine's message of vie oct 15 16:15:23 -0300 2010:
> The cfparser patch didn't change, the current version is still v1.
Hmm, this needs some cleanup; the comments still talk about the old
function name; and about just the recovery.conf file.
--
Álvaro Herrera
The Postg
Excerpts from Dimitri Fontaine's message of dom oct 17 16:30:47 -0300 2010:
> The bulk of it is now short enough to be inlined in the mail, and if you
> have more comments I guess they'll be directed at this portion of the
> patch, so let's make it easy:
>
> /*
> * We abuse some internal
Tom Lane writes:
> You could argue that either way I guess. The script knows what it
> needs, but OTOH just about every extension there is will probably
> be generating useless NOTICEs unless something is done, so maybe
> the extension management code should take care of it for them.
Either way
Dimitri Fontaine writes:
> Tom Lane writes:
>> Only if the script is intentionally noisy. The right fix here is
>> probably to bump up the min message level while running the script.
> You mean doing that from the SQL script itself (using SET) or in the
> pg_execute_from_file() code? My guess i
Tom Lane writes:
> Only if the script is intentionally noisy. The right fix here is
> probably to bump up the min message level while running the script.
You mean doing that from the SQL script itself (using SET) or in the
pg_execute_from_file() code? My guess is the former, but...
Regards,
--
Dimitri Fontaine writes:
> Robert Haas writes:
>> I don't see why. I think the real action item here is to remove =>
>> from hstore.
> As input, consider that lots of extensions will create types that are
> only a shell at the moment of the CREATE TYPE, and for each of those
> types you will se
On Tue, Oct 19, 2010 at 9:07 AM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> I don't see why. I think the real action item here is to remove =>
>> from hstore.
>
> As input, consider that lots of extensions will create types that are
> only a shell at the moment of the CREATE TYPE, and for
Robert Haas writes:
> I don't see why. I think the real action item here is to remove =>
> from hstore.
As input, consider that lots of extensions will create types that are
only a shell at the moment of the CREATE TYPE, and for each of those
types you will see the (potentially > 1000 lines long
On Oct 19, 2010, at 8:33 AM, Dimitri Fontaine wrote:
> I didn't realise that using SPI would mean dumping the all script in
> case of even NOTICEs. May be we want to protect against that in the
> CREATE EXTENSION case, but I didn't have a look at how to do it. Do we
> want CREATE EXTENSION to be m
Itagaki Takahiro writes:
> * There are some compiler warnings. You might be missing something in
> copyfuncs and equalfuncs.
Fixed in v4, attached.
> * There might be some bugs in pg_dump:
> pg_dump: schema with OID 2200 does not exist, but is needed for object
> 16411
Fixed in v4, attached.
T
Itagaki Takahiro writes:
> CREATE EXTENSION is interesting feature!
> I just compiled it and tested it via SQL commands. Here is a quick
> report.
Thanks for you time and interest!
> * There are some compiler warnings. You might be missing something in
> copyfuncs and equalfuncs.
>
> copyfu
On Mon, Oct 18, 2010 at 8:37 PM, Dimitri Fontaine
wrote:
> Here's another version of the patch, v3. Changes:
CREATE EXTENSION is interesting feature!
I just compiled it and tested it via SQL commands. Here is a quick report.
* There are some compiler warnings. You might be missing something in
c
Dimitri Fontaine writes:
>> - Bugs to fix
>>
>>There's at least one where drop extension leaves things behind,
>>although it uses performDeletion(). The dependencies are fine enough
>>so that the leftover objects are not part of the dump done before to
>>drop, though.
>
> That wel
Tom Lane writes:
> Alvaro Herrera writes:
>> Eh, I realize now that the right way to go about this is to use SPI.
>
> Yeah, that would be one way to go about it. But IMO postgres.c should
> be solely concerned with interactions with the client.
I didn't notice it's "possible" to use SPI from wi
On Sun, Oct 17, 2010 at 12:09:51AM -0300, Alvaro Herrera wrote:
> Excerpts from Tom Lane's message of sáb oct 16 23:32:49 -0300 2010:
> > Alvaro Herrera writes:
> > > The intent here is to execute some code from the file directly inside
> > > the server.
> >
> > > Eh, I realize now that the right
Excerpts from Tom Lane's message of sáb oct 16 23:32:49 -0300 2010:
> Alvaro Herrera writes:
> > The intent here is to execute some code from the file directly inside
> > the server.
>
> > Eh, I realize now that the right way to go about this is to use SPI.
>
> Yeah, that would be one way to go
Alvaro Herrera writes:
> The intent here is to execute some code from the file directly inside
> the server.
> Eh, I realize now that the right way to go about this is to use SPI.
Yeah, that would be one way to go about it. But IMO postgres.c should
be solely concerned with interactions with th
1 - 100 of 120 matches
Mail list logo
