rib.
>
> Note: the extension is NOT to be committed to core, only the first two
> patches; that will give us more room to revisit the JSON representation
> more promptly. My intention is that the extension will be published
> elsewhere.
+1 from me,
Regards,
--
Dimitri Fontaine
h
> between 1 and 6". That reads strange to me. It should be equally
> correct to spell it as "current_hour not between 1 and 6", which seems
> more natural.
True, fixed in the attached.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Form
probably also need something for the table scans in
> ALTER DOMAIN too.
Fixed in the attached version of the patch.
> You still have the ANALYZE thing in docs, which now should be removed.
Fixed in the attached version of the patch.
--
Dimitri Fontaine
uster locking strategy here, I feel like
I'm missing something obvious, as my conclusion from re-reading the code
in lights of your comment is that your comment is not accurate with
respect to the current state of the code.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Exp
y
> publish an estimated end time.
> We'd probably need some kind of time_per_block parameter for each
> tablespace so we can estimate the time.
That feels like another patch entirely.
Regards,
--
Dimitri Fontaine06 63 07 10 78
http://2ndQuadr
Dimitri Fontaine writes:
> Please find attached to this email a patch to implement a new Event
> Trigger, fired on the the "table_rewrite" event. As attached, it's meant
> as a discussion enabler and only supports ALTER TABLE (and maybe not in
> all forms of it). It wi
src/include/utils/evtcache.h| 3 +-
src/test/regress/expected/event_trigger.out | 18
src/test/regress/sql/event_trigger.sql | 21 +
7 files changed, 166 insertions(+), 6 deletions(-)
Regards,
--
Dimitri Fontaine06 63 07 10 78
http:/
Trigger idea is that the transaction is
cancelled as soon as a Rewrite Event is fired when you have installed
the protective trigger. It means that you won't see the next problem
after the first one, so it's not a dry-run.
But considering what you're saying here, it might
t case, or to maybe just do the LOCK … NOWAIT themselves in the
trigger.
For the locking parts, best would be to do the LOCK … NOWAIT dance for
all the tables touched by the DDL migration script. The Event Trigger
approach will not solve that, unfortunately.
Regards,
--
Dimitri Fontaine
reSQL release.
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
y way, and that's a real deficiency. (I once experimented with bind
> mounts to work around that -- a real mess ;-) )
Please find attached the v2 version of the patch, including fixes for
the crash and documentation aspects you've listed before.
Regards,
--
Dimitri Fontaine
Hi,
Peter Eisentraut writes:
> On 2/27/14, 6:04 AM, Dimitri Fontaine wrote:
>>directory = 'local/hstore-new'
>>module_pathname = '$directory/hstore'
>
> I think your previously proposed patch to add extension_control_path
> plus my suggestion t
ions(+), 6 deletions(-)
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
*** a/doc/src/sgml/extend.sgml
--- b/doc/src/sgml/extend.sgml
***
*** 412,417
--- 412,423
default behavior is equivalent to specifying
way, other than
$directory? I can see a use for $default_version, but that's about it.
Would you rather add support for $default_version in the patch, for all
of the parameters just in case, for a different set of control
parameters, or rename the $directory macro?
My vote goes for addin
Peter Eisentraut writes:
> I think we should get rid of the module_pathname business, and
> extensions' SQL files should just refer to the base file name and rely
> on the dynamic library path to find the files. What would we lose if we
> did that?
Control over *which* mylib.so file gets loaded
a lot of work if you're going to have to add that directory to the
> postgresql.conf path for the control file anyway to then *also* have to
> hack up the control file itself.
Given module_pathname = '$directory/xxx' the extension is now fully
relocatable and the tool doesn't
Stephen Frost writes:
> * Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
>> Who do you think should have a say about where to load the dynamic
>> librairies from? hackers, packagers, system admins, dbas or users?
>
> My gut feeling on this is packages and sysadmins. Do y
mic librairies from, which is spread into SQL scripts,
extension control file, postgresql.conf and pg_config --pkglibdir?
What exactly are you calling bizarre in the idea that the PostgreSQL
source code is maybe not the best way where to solve that problem from?
Regards,
--
Dimitri Fontaine
h
should not. Or maybe within another patch entirely.
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
bs is convoluted and
involves other people than just the PostgreSQL backend packager might be
seen as a problem or a great flexibility, in any case I don't see what
it has to do with reviewing the extension_control_path patch.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr
r. (It becomes clearer if we just have
> one path for everything. ;-) )
Again, we have directory = 'whatever' in the control file to control
where to find the script files. I'm not sure your "of course" follows.
Will still edit docs.
Regards,
--
Dimitri Fontaine
http://2
ore generally useful tool. At least we
will have some feedback about the Event Trigger specific context 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
tches with a model where the new version of the extension changes
the default_version in an auxiliary file.
We might want to instead match on the default_version in the control
file to match with the new version we are asked to upgrade to.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr Postgre
amic_library_path? If not, why do we keep 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
http://www.postgresql.org/message-id/CAOR=d=0q0dal0bnztsddnwpgm5ejkxuykj7m+qsqbr728eo...@mail.gmail.com
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make change
Tom Lane writes:
> Dimitri Fontaine writes:
>> Tom Lane writes:
>>> Why is that a good idea? It's certainly not going to simplify DBAs'
>>> lives, more the reverse. ("This dump won't reload." "Uh, where did
>>> you get that
tup PostgreSQL the way they want, then the
database guy doesn't need to know anything about that at CREATE
EXTENSION time.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
Magnus Hagander writes:
> Applied a fairly heavily edited version of this one. I also backpatched it
> to 9.1 and up.
Thanks a lot!
Did some reviewing and re-testing here, I like using DataDir and
IS_DIR_SEP better than what I did, of course ;-)
Regards,
--
Dimitri Fontain
relative path of the tablespace when found in $PGDATA, as done in
the attached.
> I've attached a slightly updated patch - I changed around a bit of logic
> order and updated some comments during my review. And added error-checking.
Thanks! I started again from your version for v3.
Rega
ails there.
The bug should be fixed against all revisions of pg_basebackup, though I
didn't try to apply this very patch on all target branches.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
*** a/src/backend/replication/basebackup.c
--
p (or an
> option to exclude it, such as when run by pg_upgrade..?). Perhaps
> similar things for pg_restore.
>
> In any case, this is certainly the way I had been hoping the discussion
> would go..
http://www.postgresql.org/message-id/18778.1354753...@sss.pgh.pa.us
--
Dimitr
x27;s a
failure, ok.
I think we need a conclusion on this thread: Extension specs are frozen.
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
UNIT` we realise with hindsight that we failed to
build a proper `EXTENSION` system, and we send that message to our users.
--
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
out and
> download the files or accepting binary .so's through the frontend
> protocol, isn't the first step in that and I very much doubt it would
> ever make sense.
That's exactly the reason why the first piece of that proposal has
absolutely nothing to do with building sai
ckage" would work
> better. I agree that "template" isn't le mot juste.
We can't use “package” because it means something very different in
direct competition. I have other propositions, but they are only
relevant if we choose not to improve Extensions… right?
Reg
make it work.
The main packaging system (debian and red hat) have automatic dependency
tracking using `ldd` or the like, so it should be possible to implement
the same thing in the software packaging and distribution layer that we
keep talking about to complement that feature.
Regards,
--
Di
some case maybe for only including
> them in verbose mode, but since sort keys are shown unconditionally,
> it seemed more consistent this way.
+1
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing lis
problems again. Circles at their best.
You just said on another thread that perfect is the enemy of good. What
about applying the same line of thoughts to this patch?
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mail
nt here. My goal is to deliver the full solution for 9.4, and
this Extension Templates facility is the missing in-core bits 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 subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
for “ready for commit” 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
x27;s OK for you.
It looks like you started with the v1 of the plperl patch rather than
the v2, where the only difference is in only using is_trigger or using
both is_trigger and is_event_trigger. Your version currently uses both
where I though we chose using is_trigger only.
Regards
various kinds of strictness, for example if they want to be
> alerted that a language cannot deal with a particular type.
My understanding is that it always can deal with any particular type if
you consider text based input/output, right?
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr Postgre
ne to someone who
never used the lisp syntax, just realise that there's nothing simpler to
parse nor “better known” (after all, it's been in wild use already for
more than 50 years).
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
e.
I understand that it can happen, it still really sucks when it does.
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
;
Then the tie breaker is the 1.0 in "create_from_version_candidates" so
we would run foo--1.0.sql and then foo--1.0--1.1.sql.
Comments?
Baring objections, I'm going to prepare a new branch to support
developping that behavior against only file based extensions, and submit
a spin-off pa
hings in this thread once.
Basically, with the extra software I want to build out-of-core, what you
have is an externally maintained repository and the scripts are
downloaded at CREATE EXTENSION time.
With the Extension Template, you then have a solid cache you can rely on
at pg_restore ti
depicted here, just in a fully automated way.
Working on a separate patch for that, 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
grade scripts from the DBA who operates the upgrades. It seems to
me it's important to keep that property.
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
using a completely different mechanism would defeat that goal. But
> I'm still not altogether happy with where that's landed us.
I'd like to better understanding what is so wrong about the current
design in terms that I'm not feeling like we did address a year ago.
th this patch set but that doesn't make it necessary.
If it's an extension, it's filtered out of pg_dump, so it's not part of
your pg_restore. Full Stop. This point has been debated and there has
been a very clear conclusion a year ago.
What am I missing here?
--
Dimitri Fontaine
we
> could provide a new make target which could build an 'inline extension'
> (or what-have-you) which could then be distributed and used by users
> either directly or with some client-side tool.
+1
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise,
and install the current default version of it.
Also runs at ALTER EXTENSION … UPDATE …, of course, providing the
upgrade scripts on the fly.
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
ed again by
pg_restore at CREATE EXTENSION time. The extension depending on its
in-catalog templates ensures that model of operations.
You can copy/paste some extension examples from the regression tests and
pg_dump -Fc | pg_restore -l to see the details, or something.
Regards,
--
Dimitri Fonta
into 9.3, if pg_dump were to
be nitpicky about the version of hstore with the command
CREATE EXTENSION hstore VERSION '1.0';
What would happen is that pg_restore would fail.
That's just the way we maintain contribs.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreS
Tom Lane writes:
> Stephen Frost writes:
>> * Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
>>> Then as soon as we are able to CREATE EXTENSION mystuff; without ever
>>> pre-installing files on the file system as root, then we would like to
>>> be able to d
write files in the right place on the file system,
usually with root privileges.
The new mechanism tries to avoid using the file system *completely*.
Sorry. I don't understand what you mean other that “I don't want this
patch because I don't understand what it is about”.
Regar
ight thing
I went for the whole set of extension abilities in my patch, you're
pushing hard for me to reduce that goal so I only included the ability
to manage version upgrades here.
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
gs, but really I don't see the
point.
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
pex extension is doing, and that's not
coincidental, but it runs the build step on the PostgreSQL server itself
and needs to have a non-trivial set of file-system privileges to be
doing so, and even needs to get root privileges with sudo for some of
its operations.
Regards,
--
Dimitri F
e system is more trustworthy as an entity than postgres on the
file system or any superuser in the PostgreSQL service.
As soon as you question that, then you might come to realise the only
difference in between file-system templates and catalog templates is our
ability to deal with the problem, rather than the problem itself.
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 to install it.
Agreed.
> I'm going to object loudly to any proposal that doesn't meet that criteria.
Please be kind enough to poin me where my current patch is drifting away
from that criteria. What you're proposing here is what I think I have
been implementing.
Regar
ibilities that
would manifest themselves as run-time errors…
So I strongly vote against making the Extension Templates a set of
shared catalogs.
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
will work on automating the choice of the
first full script to use then, for next patch version.
Thanks,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
CREATE EXTENSION time
or at ALTER EXTENSION UPDATE time, and pg_dump only contains the CREATE
EXTENSION command, so that pg_restore has to find the template again.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mai
thinking about how to make that happen other
than the following two points:
- yes I would like PostgreSQL to offer database versioning
capabilities;
- no I don't think Extensions can be made into providing support for
that set of features.
Regards,
--
Dimitri Fontaine
http://2n
model.
Also consider multi-tenancy installations. Certainly, you don't want any
database owner to be able to review PL code from any other database
owner in the same cluster when each database owner is another customer.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expert
ust find the shortest upgrade path to the version
> requested (using some arbitrary but deterministic tiebreaker)?
The danger is that the shorter path could well include a downgrade, and
nobody tests for downgrading paths IME. So I keep thinking we should ask
the extension author to gi
remote sides that know what a view is.
--
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, catalogs, default settings, etc).
I don't think you want to embed a full parser of every supported FOREIGN
version of PostgreSQL inside the postgres_fdw code, so I think the text
of the view needs to be an opaque string.
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Experti
Atri Sharma writes:
> This would work,but how can we do it for FDWs which do not parse SQL?
> Am I missing something here?
Worst case:
CREATE FOREIGN VIEW foo
AS $$
whatever syntax is accepted on the other side
$$;
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr Post
ax which is valid only on remote data source through FDW, and
> at the moment dblink interface seems feasible for that purpose.
I guess the view query would have to be validated by the FDW, which
would just receive a text.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQ
th known quals values as
constants, or something like that.
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/
The general rule being that only the role who did install the template
would be allowed to install an extension with it, so that you can't have
a privilege escalation happening, IIUC.
As a superuser, use SET ROLE first.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expe
Tom Lane writes:
> As I've said multiple times before, this is an absolute nonstarter.
FWIW, I was explaining the model that I didn't want to follow.
Thanks for approving, even if that's not a surprise as the model I did
follow is the one we agreed on a year ago.
Regards,
--
e places, then they miss out of plenty of awesome extensions.
Transforms with no granularity is only going to make it worse, I think.
So we have to choose the granularity:
- per database (current patch),
- per schema (standard has precedents with pljava,
- per extension (forcing users into us
build infrastructure in core?
My current thinking is to build the missing infrastructure as a
contrib module that will know how to divert CREATE EXTENSION with an
Event Trigger and apply the necessary magics at that time, and fill
in the Extension Templates for you.
Regards,
--
Dimi
would suggest your argument would be better
> if the use case were something more important and central to psql's purpose.
I think I just understood something entirely different that what you
were talking about.
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Format
'm sorry, but I don't understand how off-topic or hijack applies here.
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
mmon Lisp
http://www.gnu.org/software/guile/ LGPL Scheme, Javascript, Emacs Lisp
http://www.lua.org/ MIT Lua
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
nsider it as a CTE as far as the optimizer is concerned.
About FOREIGN FUNCTION, that would allow to inject arbitrary parameters
anywhere in the remote query when doing SQL functions. We have a very
nice version of FOREIGN FUNCTION already, that's plproxy.
Regards,
--
Dimitri Fontain
Peter Eisentraut writes:
> I have committed the PL/Tcl part.
> I'll work on the PL/Perl part next.
Thanks!
> I believe we're still waiting on something from you for PL/Python.
Yes I still need to figure that one out.
--
Dimitri Fontaine
http://2ndQuadrant.fr Pos
of
course (and pg_restore on a new system would depend on other 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:
http://www.postgresql.org/mailpref/pgsql-hackers
ng for text based interactive manipulation
tooling, the best I could find is the one I'm already using, Emacs ;-)
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
edly seen this
> hide bugs causing corrupted data in the end.
+1
--
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
and providing an SQL callable C function that the
trigger user might then use, or even a new WHEN clause?
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
thanks for this new Event Trigger!
--
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
t json variant in 9.2, after all.
The most popular PostgreSQL commands in 9.4 are going to be:
$ sudo apt-get install postgresql-contrib-9.4
# create extension jstore;
# alter table foo alter column documents type jstore;
# create index on foo using gist(documents);
Regards,
--
Dimitri Fo
"David E. Wheeler" writes:
> On Nov 17, 2013, at 1:51 PM, Dimitri Fontaine wrote:
>> I'm wondering about just pushing hstore in core (even if technically
>> still an extension, install it by default, like we do for PLpgSQL), and
>> calling it a day.
>
>
dding purposes, what about calling it jstore, as in “we
actually know how to store your json documents”?
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make change
ent:
CREATE FUNCTION foo (hash hstore WITH TRANSFORM, kv hstore) …
I certainly hope we don't need that, and sure can't imagine use cases
for that level of complexity at the time of writing this review.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation
and
> features in situations where we previously weren't.
+1
Maybe what needs to happen to this patch is away to restrict its usage
to --single. I'm thinking that postgres --single maybe could be made to
fork the server process underneath the psql controler client process
transpar
y IBM stock price on any exchange
>>
>>
>> My request is to implement the same or similar feature in Postgresql.
>
> This does seem useful and pretty easy to implement. Should we add a
> TODO?
I think we should consider the ltree syntax in that case, as documented
in
hat's about it.
> I'll still go ahead and start looking through this, per our discussion.
Thanks!
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
templates.v16.patch.gz
Description: Binary data
--
Sent via pgsql-hackers mailing list (p
ll, yeah ok, my idea is a non-starter.
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
er than a btree index over the hash
function.
Comments?
--
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
ll" location for them.
See also my proposal to solve that, I'd welcome some design level
discussions about it:
http://www.postgresql.org/message-id/m28uyzgof3@2ndquadrant.fr
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
We would just be
unable to answer interesting questions with just that.
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 RECHECK bits.
Then again I'm talking from 8.3 era memories of when I tried to
understand GiST enough to code the prefix extension.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
e as simple as
moving the T_ClusterStmt case from standard_ProcessUtility() down to the
Event Trigger friendly part known as ProcessUtilitySlow().
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list
al_senders actually ;-)
My vote would be to have default to at least 3, so that you can run both
a pg_basebackup -Xs (stream) and a standby or a pg_receivexlog in
parallel. Maybe 5 is an even better default.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et
1 - 100 of 1920 matches
Mail list logo
