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 subscripti
Álvaro and Tom, so my
guess is that's ok :)
> * In the snippet below, it seems best just to use palloc0():
> query_string = (char *)palloc((fsize+1)*sizeof(char));
> memset(query_string, 0, fsize+1);
Edited.
> * Shouldn't it include SPI_push() and SPI_pop()?
ENOCLU
ed as part of this very patch.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
*** a/doc/src/sgml/ref/alter_conversion.sgml
--- b/doc/src/sgml/ref/alter_conversion.sgml
***
*** 23,28 PostgreSQL documentation
--- 23,29
A
L and
check for changes.
Regards,
--
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://www.postgresql.org/mailpref/pgsql-hackers
ary doing so when using
SPI_execute(), which is the case here:
http://www.postgresql.org/docs/9.0/interactive/spi-spi-push.html
Note that SPI_execute and related functions automatically do the
equivalent of SPI_push before passing control back to the SQL
execution engine, so it is not n
e. It's more a VCS and
editor friendly export, to be able to see diffs that come from the real
current database state rather than what your code tracking makes you
think is in production already.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
es
4. alter extension set schema
https://commitfest.postgresql.org/action/patch_view?id=416
needs review and a reviewer
will need bitrot fix (and adding in the _oid variants)
would be better to adjust once the 3 previous are in
Regards,
--
Dimitri Fontaine
http://2ndQuad
nt situation by having as good an
view of the bigger picture as what you have now sounds great.
Regards,
--
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 su
client_encoding before to call into pg_execute_from_file(). So I'd hope
that changing that client side just before to call pg_execute_from_file
would be enough. Is it?
Regards,
--
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://www.postgresql.org/mailpref/pgsql-hackers
to land in core. Two particular examples come to mind, which are tsearch
and KNN GiST. The main problem with integrating into core, AFAIUI, are
related to code maitenance, not at all with code stability and quality
of the addon itself.
It's just so much easier to develop an external module…
R
h, and following Tom's
advices.
Regards,
--
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://www.postgresql.org/mailpref/pgsql-hackers
the query in PG_GETARG_TEXT_P(0)?
> On Mon, Nov 29, 2010 at 11:48 AM, Tom Lane wrote:
>> Robert Haas writes:
>> What did you think of "pg_execute_sql_file"?
>
> That, I like.
Ok, I call pg_execute_sql_file() the winner and will prepare a new patch
later tonight, now is comu
g text
rather than bytea, too, and if we choose to fix that rather than adding
some new functions, we will want to avoid having to separate the two
functions again.
> * I hope pg_execute_from_file (and pg_read_file) had an option
> to specify an character encoding of the file. Especially, SJIS
pg_execute_from_file patch? If so, I'll prepare v7 with that.
Overall, I'd like it if it'd be possible to separate the concerns
directly relevant to the extension patch to other legitimate ones, so
that the main patch gets its share of review in this commitfest. But
maybe I
m client_encoding to server_encoding),
> it still won't work well when error messages are raised. The client
> expects the original client encoding, but messages are sent in the
> file encoding. It would be a security hole.
I'll confess I'm at a loss here wrt how to solve y
you don't think it's big enough, think about web environments
and pgbouncer in transaction pooling mode. Loads of fun.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers
e server with the new
code compiled in. I'm not sure it's that important in the context of
preparing 9.1. It seems that pg_upgrade already has to issue a reindex
script for GiST indexes.
Now, of course, that's memories from Royal-Oak sessions, so it might be
all wrong t
anymore in recent kernels. An example of
trustworthy setting is fdatasync.
Regards,
--
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://www.postgresql.org/mailpref/pgsql-hackers
lpgsql block (in which case that's supported for free) or about a new
plain SQL variant of it?
Regards,
--
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
ded to
cope with the newer consistent API, I guess. Will stop commenting now
until I've had the time to read the code :)
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
Dimitri Fontaine writes:
> Itagaki Takahiro writes:
>> My suggestion is to introduce pg_read_binary_file() function that can
>> read any files in the server, and make CREATE EXTENSION to use the
>> function. Of course, pg_execute_[sql|from]_file() can simplify queries
in the code, it's actually convert then execute. But again,
maybe some Native Speaker will have a say here, or maybe your proposed
name fits better in PostgreSQL. I'd leave it for commiter :)
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Suppo
the idea discussed and some patches
to implement it, by Simon. I suppose you could begin here:
http://archives.postgresql.org/pgsql-patches/2008-06/msg00113.php
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mai
total pg_dump
duration is then reduced to about the time to dump the biggest files.
Regards,
--
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:
ht
Joachim Wieland writes:
> A guy called Dimitri Fontaine actually proposed the
> serveral-directories feature here and other people liked the idea.
Hehe :)
Reading that now, it could be that I didn't know at the time that given
a powerful enough subsystem disk there's no way to
right and naming here is good news.
BTW, I see you already made that happen (and so much more) in your v9
patch, thank you very much about that! Follow-up due later this morning!
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql
this line of thought, maybe we should provide a third variant
here, the "real" pg_read_whole_file(path), then we have the existing
other variants, pg_read_file_to_end(path, offset) and the historic one,
pg_read_file(path, offset, bytes_to_read).
Regards,
--
Dimitri Fontaine
http://2nd
Regards,
--
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://www.postgresql.org/mailpref/pgsql-hackers
to.
You won't find a single contrib module containing those either, with or
without my patch.
> * One could specify stuff *only* in the `Makefile` and let `make`
> create a control file.
Been trying, failed. Sorry.
> * I could omit the @extschema@ business altogether and just let CREATE
right? :)
Regards,
--
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://www.postgresql.org/mailpref/pgsql-hackers
Given such an agenda, I'd argue for a feature branch being open for
partitioning so that incremental reviewed work can happen there until we
have enough pieces to consider merging into HEAD.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Sup
dy what has been
happening here for some years, with *zero* success. I'm trying to
understand what we (as the community) intend to do about it, I'm *not*
trying to open yet another private-branch-then-rejected-patch.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Exper
ore typical yet,
Pizza restaurants around a known place :)
Regards,
--
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://www.postgresql.org/mailpref/pgsql-hackers
e a patch, I'm not sure about being able
to send it to the list before Thursday --- unless I get around the git
network errors at pgday.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subs
on of
> a SQL function in an extension, to prevent search-path-related security
> issues in the use of the function. Without substitution you'll be
> reduced to hard-wiring the name of the target schema.
Right.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
done someday before we
consider a merge".
Do you prefer this all to happen externally and without commiters
helping in the incremental effort? I can see the burden if we include
such topic branch in our existing processes, but also the advantages.
You call that a judgement call, right
y is. I'm not sure I ever
> would have figured it out myself, given that it works just fine if I
> install it the old-fashioned way (psql -f).
I'd need some input on how to fix SPI to support that.
>>> * I could omit the @extschema@ business altogether and just let CREATE
>>> EXTENSION set the path for the duration of its execution.
>>
>> That won't fly.
>
> Why not?
What you want is to know that the script did create its objects into the
schema you're giving, but there's no reason the script is not
hard-coding the schema, or using more than one. Back to the 2-steps idea.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
your idea here, we could make it so that only the non-relocatable
extensions benefit from the @extschema@ placeholder.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
SET log_min_messages TO warning;
>
> Though I think I'd rather that the warning still went to the log.
(that's about hstore verbosity) ok will see about changing
client_min_messages around the CREATE OPERATOR =>.
Regards,
--
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://www.postgresql.org/mailpref/pgsql-hackers
ad. It's just that if you want correctness, you don't have anything
better.
Regards,
--
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
at's
not a burden for the user. So that simple things are simple both for the
extension's author and the users, but complex things still possible and
supported here.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hac
ks it's a good idea to break the extension
after it's been installed, I'm not sure we can do anything about it.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
after
> the fact by altering the contained objects? Sure, but he could break
> the extension in any number of other ways as well by making such
> alterations. The answer to that is privilege checks, and superusers
> being presumed to know what they're doing.
+1
Regards,
--
Dimitri
internals of the SQL parser into SPI so that
you can send a bunch of queries in an explicit way. Mind you, the
firsts version of the patch had something like that in there, but that
wouldn't have supported this use case. I've been told to simply use SPI
there.
Regards,
--
Dimitri Fo
"David E. Wheeler" writes:
> I don't see why. Most of them are dead simple and could easily be
> Makefile variables.
And how does the information flows from the Makefile to the production
server, already?
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL :
"David E. Wheeler" writes:
>> And how does the information flows from the Makefile to the production
>> server, already?
>
> `make` generates the file if it doesn't already exist.
Again, will retry when possible, but it has been a time sink once al
Dimitri Fontaine writes:
> Well it does not seem to be complex to code. It's about having a new
> property in the control file, relocatable, boolean. This property is
> required and controls the behavior of the CREATE EXTENSION ... WITH
> SCHEMA command. When true we use the AL
tp://www.pastie.org/684163
It that this one ?
http://archives.postgresql.org/message-id/e08cc0400911042333o5361b21cu2c9438f82b1e5...@mail.gmail.com
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers
"David E. Wheeler" writes:
> On Dec 9, 2010, at 12:34 PM, Dimitri Fontaine wrote:
>> - add support for 'relocatable' boolean property in the control file,
>> as discussed on list
>
> This still isn't ideal, but I think it's a big improvement.
ver eases maintenance.
Oh and in PostgreSQL sources cases, that would add like 36 spots where
to manually maintain our major version string. I'm not eager to do that.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql
ite
different there.
Regards,
--
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://www.postgresql.org/mailpref/pgsql-hackers
s upgrading, we would
still provide for an upgrade path in the script / sql support so that
the version number has a chance of being upgraded too. As you say in
another mail, of course, the OS packaging system will not forcibly be
willing to care for that all by itself. I can imagine debian offer
ts.
Of course if calling the script succeeds, then the version number in the
pg_extension catalog is changed to the "next" one.
Now, it would be better if it were easy to compare version numbers, for
example with a -core datatype that handles that. Do we already want to
open this can of worms?
Re
or releases.
The part that will drop in interest is the one where customers are not
trusting the extension mechanism and third-party software enough to
grant them landing into their production environments. Maybe. Given some
years and a good track record.
Regards,
--
Dimitri Fontaine
http://2ndQuad
put the script name? We would have to support a way for this filename
to depend on the already installed version, I'm thinking that %v might
be the easiest here (read: I want to avoid depending on any version
scheme).
version = '13'
script = 'foo.sql'
upgrade = &
quire some kind of "upgrade all" command for
> contrib.
That's as easy as having non-continuous version numbering. In your
example, we get from dblink version 9.1.0 to 9.1.4, but the 3 releases
before that it remains dblink 9.1.0.
Would it cut it?
--
Dimitri Fontaine
http://2ndQuad
"David E. Wheeler" writes:
> On Dec 10, 2010, at 1:50 PM, Dimitri Fontaine wrote:
>> I don't think we can safely design around one part version numbers here,
>> because I'm yet to see that happening in any extension I've had my hands
>> on, which me
ows me not to have to think about
*any* files naming rules nor version numbering scheme.
Regards,
--
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://www.postgresql.org/mailpref/pgsql-hackers
ok with that too.
So, we have a sound proposal for the ALTER EXTENSION UPGRADE command,
which comes later. So we keep version numbers in the CREATE EXTENSION
patch and the control files, and remove the facility to get this number
from the Makefile. Is that right?
Regards,
--
Dimitri Fontai
sql'
Where the version here is the version you're upgrading *from* (to is
known and static when you distribute the files after all), and where
upgrade_all is applied last no matter what got applied before.
Also, do we want a subdirectory per extension to host all those files?
Regard
functions (those placeholders idea).
The git tree already contains a fixed extension code, but the next patch
for that one will have to wait some more (psql refactoring).
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
*** a/doc/src/sgml/func.sgml
RESTART TRUNCATE or ON RESTART FLUSH, I guess?
Regards,
--
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://www.postgresql.org/mailpref/pgsql-hackers
Alexander Korotkov writes:
> Here is first version of patch, which enable index support of wildcard
> search in pg_trgm contrib module.
How different (and better) is it from wildspeed?
http://www.sai.msu.su/~megera/wiki/wildspeed
Regards,
--
Dimitri Fontaine
http://2ndQuadr
uch as Kevin's one seems to warrant
that we are able to create a table withouth enforcing the FK. That's
horrid, yes, that's needed, too. Maybe some operations would have to be
instructed that the constraint ain't trustworthy but just declared to be
so by the user?
Regards,
--
Dimitr
e "utils/array.h" anymore.
Ah yes, true.
Do you want another patch version from me?
--
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://www.postgresql.org/mailpref/pgsql-hackers
upgrade-2.* = $EXT-upgrade-2.sql
Problem is: what to do if a single upgrade matches more than one line?
The only safe answer is to error out and refuse to upgrade but that
ain't nice to the user. How much is that a problem here?
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr Post
lf:
upgrade-1.* = 'upgrade-1.sql'
upgrade-2.* = 'upgrade-2.sql'
Regards,
--
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
o's in to finish up and commit this patch in this round? :)
I certainly am ready to support last minute changes, given some are
required. And if they are too big for the schedule, better shake the
patch out now rather than let it bitrot another month.
Regards,
--
Dimitri Fontaine
http://2nd
"David E. Wheeler" writes:
> On Dec 13, 2010, at 12:04 PM, Dimitri Fontaine wrote:
>> So, who's in to finish up and commit this patch in this round? :)
>
> I'll try to do another review this week.
Thanks!
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQ
ht version of
the patch, and if necessary, revise it.
Regards,
--
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://www.postgresql.org/mailpref/pgsql-hackers
aste in the code rather than in the mail.
That schedule optimisation is for you to make, though.
Regards,
--
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 subscrip
Robert Haas writes:
> Well, I think it is best when a patch has just one purpose. This
> seems to be sort of an odd hodge-podge of things.
The purpose here is clean-up the existing pg_read_file() facility so
that it's easy to build pg_execute_sql_file() on top of it.
Regards,
ction scope would mean pure SQL
function work). Thanks! :)
Regards,
--
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://www.postgresql.org/mai
tail only, but let's be clear what it is
> we're talking about.
Hence the refactoring in the patch. Ask Itagaki for details with funny
environments using some file encoding that does not exists in the server
yet ain't client_encoding and can't be. I didn't follow t
ext".
Yeah, yeah. Now, what's wrong with the query I sent?
To ease discussion:
=# select objid
from pg_extension_objects('hstore')
where class = 'pg_type'::regclass and objdesc ~ '(^|\.)hstore$';
objid
---
16387
(1 row)
Regards,
--
Dimitri
g_type |1247 | 16387 | type utils.hstore
pg_type |1247 | 16392 | type utils.hstore[]
pg_type |1247 | 16466 | type utils.ghstore
pg_type |1247 | 16469 | type utils.ghstore[]
(4 rows)
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Su
ension e
LEFT JOIN pg_catalog.pg_depend d ON d.objid = e.oid
AND d.refclassid = 'pg_catalog.pg_namespace'::regclass
LEFT JOIN pg_catalog.pg_namespace n ON n.oid = d.refobjid
WHERE extname = 'hstore';
nspname | extname
-+-
Itagaki Takahiro writes:
> I applied the attached patch extracted from Dimitri's work.
Thanks! I'm working on next extension's patch, merging now.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers m
Robert Haas writes:
> On Thu, Dec 16, 2010 at 7:49 AM, Dimitri Fontaine
> wrote:
>> Please note that the SQL scripts seem to be encoded in latin9.
>
> Seems like an odd choice. Why not UTF-8?
Not a choice, just what's already in…
--
Dimitri Fontaine
http://2ndQua
each release. We need to find a better way
> to fix this.
+1.
Naively enough, getting this from the Makefile looked obvious to me.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
er support doesn't prevent anything
here, it just allows some more flexibility. That was considered some
more complexity not solving any real world use-case on-list, though.
FWIW, it seems very likely that should we ship without the Make support
I'll have to add it to every extension I ma
maintenance
burden. And extension authors will probably be asking for some more
facilities too, by then.
Regards,
--
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://www.postgresql.org/mailpref/pgsql-hackers
Dimitri Fontaine writes:
> Tom Lane writes:
>> However, the only way I can see to fix this "automatically" is to have
>> the makefiles propagate PG_VERSION_NUM (or one of the other values set
>> by configure) into generated control files.
>
> Ah, somewhat lik
CREATE EXTENSION XXX". They are a
> bit different because CREATE EXTENSION uses the installed sql files instead
> of the source directory. But I think this is the correct behavior. We should
> have used only installed files because they are used in "make *installcheck*".
#x27;encoding' parameter in the control file there.
Itagaki required that the extension code is encoding aware, and it
wasn't clear that the control file 'encoding' parameter would be enough
in his side of the world, so the encoding support is currently offered
to authors in
hanism evolving in several directions. Either we
remove it entirely, or we add a list ok known custom_variable_classes
and SINVAL support for it so that as soon as the setting changes, all
concurrent backends know about it, and so that you have a catalog cache
to walk through rather than a real cata
Sure. I'm curious about understanding how it's broken and if there's
any will at all to have something better (and what better would be), but
it's now obvious that it's not going to help the extension patch.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : E
ample, at SHOW, searching pg_settings,
> or assignment to variables with unknown classes.
Just so that we're on the same line here, if we are to remove
custom_variable_classes then we don't keep any GUC related code into the
extension patch, right? So that ExtensionSetCVC() and friends dis
ort it and user documentation to explain it.
The whole documentation needs to be:
encoding
The encoding in which the script file is read.
The code to support that is on the order of 25 lines of code, once we
get rid of the SQL command level
with what's in
a specific database and no use at all of placeholder GUCs, right?
Regards,
--
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:
htt
need more consideration about where to do it.
I checked for doing that too, but both shared_preload_libraries and
local_preload_libraries are managed way earlier than the point where we
can connect to a database a check what extensions it contains. So that
appeared to me as a dead-end.
Regards,
--
-extension.git;a=shortlog;h=refs/heads/extension
Regards,
--
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://www.postgresql.org/mailpref/pgsql-hackers
tgresql-extension.git;a=commitdiff;h=9371a9763651df2636cb6c20dced7cd67398c477
It was already online for readers of the HTML version of the docs:
http://pgsql.tapoueh.org/extensions/doc/html/sql-alterextension.html
And it will appear in next revision of the patch. Thanks!
--
Dimitri Fontaine
r. I compiled but didn't
> run it :-)
Thanks a lot, that's applied in my git repo, and I did run it
successfully! It will be part of the next patch revision.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-h
"Erik Rijkers" writes:
>> http://pgsql.tapoueh.org/extensions/doc/html/sql-alterextension.html
[...]
> Two changes to sql-alterextension.sgml:
Fixed and uploaded on the URL above, will be in the next patch revision,
thanks!
Regards,
--
Dimitri Fontaine
http://2ndQuadran
p://tsung.erlang-projects.org/
http://archives.postgresql.org/pgsql-admin/2008-12/msg00032.php
Regards,
--
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 su
ame name has been taken out. As a result
we do not have pg_execute_from_file() nor pg_execute_sql_file() in
alpha3 and we won't have it later with extensions.
There's the configuration file parsing merge that we might want to tell
users about. You no longer have to follow different quot
Joel Jacobson writes:
> Solution: I propose a new option to pg_dump, --split, which dumps each
> object to a separate file in a user friendly directory structure:
Please have a look at getddl:
https://github.com/dimitri/getddl
Regards,
--
Dimitri Fontaine
http://2ndQuadr
ction for it...
>
> That's definitely another option that I wouldn't object to if people
> prefer that way.
+1.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
upgrade', including how to
upgrade from pre-9.1 extensions. But if that flies quicker than I want,
count me in for more than only user specs :)
Regards,
--
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://www.postgresql.org/mailpref/pgsql-hackers
401 - 500 of 1920 matches
Mail list logo
