Re: [HACKERS] jsonb and nested hstore
On Wed, Mar 5, 2014 at 4:24 PM, Stephen Frost sfr...@snowman.net wrote: * Merlin Moncure (mmonc...@gmail.com) wrote: On Wed, Mar 5, 2014 at 2:46 PM, Stephen Frost sfr...@snowman.net wrote: I don't see why we can't do exactly what you're suggesting in core. Because you can't (if you're defining core to mean 'not an extension'). Functions can't be removed or changed because of legacy application support. In an extension world, they can -- albeit not 'magically', but at least it can be done. That simply isn't accurate on either level- if there is concern about application support, that can apply equally to core and contrib, and we certainly *can* remove and/or redefine functions in core with sufficient cause. It's just not something we do lightly for things living in either core or contrib. For an example, consider the FDW API, particularly what we did between 9.1 and 9.2. Well, we'll have to agree to disagree I suppose. Getting back on topic, the question is 'what about jsonb/hstore2'? At this point my interests are practical. I promised (heh) to bone up the docs. I'm on vacation this weekend so it's looking like around sometime late next week for that. In particular, it'd be helpful to get some kind of read on the final disposition of hstore2. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_ctl status with nonexistent data directory
On Mon, Nov 4, 2013 at 11:31:30AM -0500, Robert Haas wrote:
On Sat, Nov 2, 2013 at 3:32 PM, Peter Eisentraut pete...@gmx.net wrote:
This doesn't seem right:
$ pg_ctl -D /nowhere status
pg_ctl: no server running
It does exit with status 3, so it's not all that broken, but I think the
error message could be more accurate.
I doubt anyone will object if you feel the urge to fix it. I won't, anyway.
I have addressed this issue with the attached patch:
$ pg_ctl -D /lkjasdf status
pg_ctl: directory /lkjasdf does not exist
$ pg_ctl -D / status
pg_ctl: directory / is not a database cluster directory
One odd question is that pg_ctl status has this comment for reporting
the exit code for non-running servers:
printf(_(%s: no server running\n), progname);
/*
* The Linux Standard Base Core Specification 3.1 says this should return
* '3'
*
https://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html
*/
exit(3);
If they haven't passed us a data directory, we don't really know if the
server is running or not, so the patch just returns '1'.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
diff --git a/src/bin/pg_ctl/pg_ctl.c b/src/bin/pg_ctl/pg_ctl.c
new file mode 100644
index 0dbaa6e..90c98ee
*** a/src/bin/pg_ctl/pg_ctl.c
--- b/src/bin/pg_ctl/pg_ctl.c
*** static bool allow_core_files = false;
*** 97,102
--- 97,103
static time_t start_time;
static char postopts_file[MAXPGPATH];
+ static char version_file[MAXPGPATH];
static char pid_file[MAXPGPATH];
static char backup_file[MAXPGPATH];
static char recovery_file[MAXPGPATH];
*** get_pgpid(void)
*** 250,255
--- 251,275
{
FILE *pidf;
long pid;
+ struct stat statbuf;
+
+ if (stat(pg_data, statbuf) != 0)
+ {
+ if (errno == ENOENT)
+ printf(_(%s: directory \%s\ does not exist\n), progname,
+ pg_data);
+ else
+ printf(_(%s: cannot access directory \%s\\n), progname,
+ pg_data);
+ exit(1);
+ }
+
+ if (stat(version_file, statbuf) != 0 errno == ENOENT)
+ {
+ printf(_(%s: directory \%s\ is not a database cluster directory\n),
+ progname, pg_data);
+ exit(1);
+ }
pidf = fopen(pid_file, r);
if (pidf == NULL)
*** main(int argc, char **argv)
*** 2285,2290
--- 2305,2311
if (pg_data)
{
snprintf(postopts_file, MAXPGPATH, %s/postmaster.opts, pg_data);
+ snprintf(version_file, MAXPGPATH, %s/PG_VERSION, pg_data);
snprintf(pid_file, MAXPGPATH, %s/postmaster.pid, pg_data);
snprintf(backup_file, MAXPGPATH, %s/backup_label, pg_data);
snprintf(recovery_file, MAXPGPATH, %s/recovery.conf, pg_data);
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] exit_horribly vs exit_nicely in pg_dump
On Wed, Nov 6, 2013 at 08:47:43AM -0500, Peter Eisentraut wrote:
On 11/5/13, 8:46 AM, Pavel Golub wrote:
I suppose this should be call to exit_nicely() for all possible cases.
The only need for calling exit_horribly() is when we are deep down in
the multithreaded code, AFAIK.
Doesn't hurt either, though. But it would be OK to make this more
consistent.
Fixed in attached applied patch.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c
new file mode 100644
index f5a6bbb..17bb846
*** a/src/bin/pg_dump/pg_dump.c
--- b/src/bin/pg_dump/pg_dump.c
*** main(int argc, char **argv)
*** 563,572
dump_inserts = 1;
if (dataOnly schemaOnly)
! exit_horribly(NULL, options -s/--schema-only and -a/--data-only cannot be used together\n);
if (dataOnly outputClean)
! exit_horribly(NULL, options -c/--clean and -a/--data-only cannot be used together\n);
if (dump_inserts oids)
{
--- 563,578
dump_inserts = 1;
if (dataOnly schemaOnly)
! {
! write_msg(NULL, options -s/--schema-only and -a/--data-only cannot be used together\n);
! exit_nicely(1);
! }
if (dataOnly outputClean)
! {
! write_msg(NULL, options -c/--clean and -a/--data-only cannot be used together\n);
! exit_nicely(1);
! }
if (dump_inserts oids)
{
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Unportable coding in reorderbuffer.h
On 2014-03-05 17:40:56 -0500, Tom Lane wrote:
I don't believe that this is legal per C90:
typedef struct ReorderBufferChange
{
XLogRecPtrlsn;
/* type of change */
union
{
enum ReorderBufferChangeType action;
/* do not leak internal enum values to the outside */
intaction_internal;
};
...
That union field needs a name.
You're absolutely right.
Our project standard is we compile on C90 compilers, and we're not
moving that goalpost just to save you a couple of keystrokes.
While it's a good idea to try to save keystrokes the actual reason is
that I just had somehow forgotten that it hasn't always been
supported. I think it's not even C99, but C11...
By the time you get done fixing the portability issue, I suspect you
won't have a union at all for the first case.
You might be right. I'd rather not leak the internal enum values to the
public though, so there are two choices:
* define as enum, but store values in the that aren't actually valid
members. IIRC that's legal, even if not pretty. Anything outside
reorderbuffer.c doesn't ever see the values that aren't enum values.
* define it as an int, but suggest casting to the enum inside switch()
in examples/docs.
I'm not real sure that
you need a union for the second case either --- is it really important
to shave a few bytes from the size of this struct? So you don't
necessarily need to do a notation change for the second union.
I think it's allocated frequently enough to warrant that
unfortunately. Changing that will be fun.
What drew my attention to it was an older gcc version complaining
thusly: [errors]
And there I was, suprised it hadn't turned the buildfarm red.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Unportable coding in reorderbuffer.h
Andres Freund and...@2ndquadrant.com writes: On 2014-03-05 17:40:56 -0500, Tom Lane wrote: By the time you get done fixing the portability issue, I suspect you won't have a union at all for the first case. You might be right. I'd rather not leak the internal enum values to the public though, so there are two choices: * define as enum, but store values in the that aren't actually valid members. IIRC that's legal, even if not pretty. Anything outside reorderbuffer.c doesn't ever see the values that aren't enum values. * define it as an int, but suggest casting to the enum inside switch() in examples/docs. Meh. I think you're being *way* too cute here. I'd just put all the values in one enum declaration, and use comments and/or naming convention to mark some of them as internal and not meant to be used outside the reorderbuffer stuff. That will for one thing allow gdb to print all the values properly. And somebody who's bound and determined to violate the abstraction could do it anyway, no? What drew my attention to it was an older gcc version complaining thusly: [errors] And there I was, suprised it hadn't turned the buildfarm red. I'm surprised too; I had thought we still had some critters running hoary compilers. We need to do something about that if we actually believe in C90-compiler support. I experimented a little bit and found that modern gcc with -ansi (aka -std=c89) will complain about this particular issue, and it also complains about // comments which are a perpetual hazard; but it is still happy about a lot of other not-C90 things like flexible array members. We could try spinning up a buildfarm critter with -ansi -pedantic but I'm not sure if that's much better. The GCC man page warns that these options are not meant to be a strict check for C90 standard compliance, and anyway the important question is not whether gcc with options that nobody uses will take our code, its whether old compilers that are still in real use will take it. For a long time I was using gcc 2.95.3 on my HPPA dinosaur as a reference for hoary-compiler behavior. That machine is now flaky enough that I don't want to keep it turned on 24/7, but maybe I could compile up 2.95.3 on some other box and start a buildfarm critter. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] missing RelationCloseSmgr in FreeFakeRelcacheEntry?
On Tue, Nov 5, 2013 at 08:36:32PM +0100, Andres Freund wrote: On 2013-11-04 13:48:32 +0100, Andres Freund wrote: What about just unowning the smgr entry with if (rel-rd_smgr != NULL) smgrsetowner(NULL, rel-rd_smgr) when closing the fake relcache entry? That shouldn't require any further changes than changing the comment in smgrsetowner() that this isn't something expected to frequently happen. Attached is a patch doing it like that, it required slightmy more invasive changes than that. With the patch applied we survive replay of a primary's make check run under valgrind without warnings. Where are we on this patch? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GSoC proposal - make an unlogged table logged
On Tue, Mar 4, 2014 at 5:00 PM, Fabrízio de Royes Mello fabriziome...@gmail.com wrote: On Tue, Mar 4, 2014 at 3:29 PM, Andres Freund and...@2ndquadrant.com wrote: On 2014-03-04 12:54:02 -0500, Robert Haas wrote: On Tue, Mar 4, 2014 at 9:50 AM, Andres Freund and...@2ndquadrant.com wrote: On 2014-03-04 09:47:08 -0500, Robert Haas wrote: Can't that be solved by just creating the permanent relation in a new relfilenode? That's equivalent to a rewrite, yes, but we need to do that for anything but wal_level=minimal anyway. Yes, that would work. I've tended to view optimizing away the relfilenode copy as an indispensable part of this work, but that might be wrongheaded. It would certainly be a lot easier to make this happen if we didn't insist on that. I think it'd already much better than today's situation, and it's a required codepath for wal_level logical anyway. So even if somebody wants to make this work without the full copy for minimal, it'd still be a required codepath. So I am perfectly ok with a patch just adding that. Then is this a good idea for a GSoC project ? I don't know very well this internals, but I am willing to learn and I think the GSoC is a good opportunity. Any of you are willing to mentoring this project? Hi all, I written the proposal to this feature, so I would like to know if someone can review. proposal ** Add to PostgreSQL the capacity to making an Unlogged table Logged ** Introduction This project will allow to change an unlogged table (that doesn't create transaction logs - WAL files) and it's dependencies to a logged table, in other words, a regular table that create WAL files. To make this happen we'll introduce a new SQL syntax: ALTER TABLE name SET LOGGED; Benefits to the PostgreSQL Community The unlogged tables feature was introduced by 9.1 version, and provide better write performance than regular tables (logged), but are not crash-safe. Their contents are automatically discarded (cleared) in a case of a server crash, and their contents do not propagate to replication slaves, either. With the capacity of turning an unlogged table in a logged table will allow us have the better of two features, in other words, we can use an unlogged table to run a bulk load a thousands of lines (ETL scripts) and get better performance, and then change it to a logged table to get durability of loaded data. Deliverables This project will be splitted into 2 (two) deliverables: 1) Allow change an unlogged table to logged when wal_level = minimal (without propagate their contents to replication slaves) 2) Allow change an unlogged table to logged when wal_level != minimal (propagating their contents to replication slaves) Project Schedule until May 19: * create a website to the project (wiki.postgresql.org) * create a public repository to the project (github.com/fabriziomello) * read what has already been discussed by the community about the project ( http://wiki.postgresql.org/wiki/Todo) * discuss with the community the best design to the feature * learn about some PostgreSQL internals: . physical storage for relations (src/backend/catalog/storage.c) . transaction system (src/backend/access/transam/xact.c) . two-phase commit (src/backend/access/transam/twophase.c) . table commands (src/backend/commands/tablecmds.c) . grammar (src/backend/parser/gram.y) May 19 - June 23 * evaluate with the mentor and community if is a good start point use the already sent patch ( http://www.postgresql.org/message-id/263033.9223...@web29013.mail.ird.yahoo.com ) * implementation of the first deliverable: . change the grammar of PostgreSQL to support ALTER TABLE ... SET LOGGED . implement the routines to change an unlogged table to logged when wal_level = minimal * write documentation and the test cases * submit this first deliverable to the commitfest 2014/06 ( https://commitfest.postgresql.org/action/commitfest_view?id=22) June 23 - June 27 * review with the Mentor of the work done until now June 27 - August 18 * implementation of the second deliverable (wal_level != minimal) * write documentation and the test cases * submit this second deliverable to the commitfest 2014/09 (webpage don't created yet) August 18 - August 22 * final review with the Mentor of all work done. About the proponent Fabrízio de Royes Mello e-mail: fabriziome...@gmail.com twitter: @fabriziomello github: http://github.com/fabriziomello linkedin: http://linkedin.com/in/fabriziomello Currently I help people and teams to take the full potential of relational databases, especially PostgreSQL, helping teams to design the structure of the database (modeling), build physical architecture (database schema), programming (procedural languages), SQL (usage, tuning, best practices), optimization and orchestration of instances in production too. I perform a volunteer work for Brazilian Community of PostgreSQL (www.postgresql.org.br), supporting mailing
Re: [HACKERS] Unportable coding in reorderbuffer.h
On 2014-03-05 19:12:15 -0500, Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: On 2014-03-05 17:40:56 -0500, Tom Lane wrote: By the time you get done fixing the portability issue, I suspect you won't have a union at all for the first case. You might be right. I'd rather not leak the internal enum values to the public though, so there are two choices: * define as enum, but store values in the that aren't actually valid members. IIRC that's legal, even if not pretty. Anything outside reorderbuffer.c doesn't ever see the values that aren't enum values. * define it as an int, but suggest casting to the enum inside switch() in examples/docs. Meh. I think you're being *way* too cute here. I'd just put all the values in one enum declaration, and use comments and/or naming convention to mark some of them as internal and not meant to be used outside the reorderbuffer stuff. That will for one thing allow gdb to print all the values properly. And somebody who's bound and determined to violate the abstraction could do it anyway, no? The reason I'd like to avoid the internal members in the public enum isn't so much that I want to avoid the internal names being visible to the outside, but that I find it very helpful to see compile time warnings about public enum values not being handled in output plugins. I am pretty sure we're going to add further features in the not too far away futures and it seems nicer to be able to warn that way. But I guess it's too much work, for not enough benefit :( What drew my attention to it was an older gcc version complaining thusly: [errors] And there I was, suprised it hadn't turned the buildfarm red. I'm surprised too; I had thought we still had some critters running hoary compilers. We need to do something about that if we actually believe in C90-compiler support. What version was the gcc that triggered the error? I have to admit that I am really not interested in supporting gcc 2.95 , that thing is just too old (nearly 15 years!) and buggy. But it's not a small step from desupporting 2.95 to having gcc 3.4 (protosciurus, narwahl) as the minimum. And it should be a conscious not implicit decision. It'd be really helpful to have some more buildfarm animals running real-world relevant older compilers. I'd be surprised if this is the only such issue lurking around. As I've compiled it anyway while thinking about gcc versions, here's the lifetimes of various gcc releases: version first version last version --- 2.95July 31, 1999 March 16, 2001 3.0 June 18, 2001 December 20, 2001 3.1 May 15, 2002July 27, 2002 3.2 August 14, 2002 April 25, 2003 3.3 May 14, 2003May 3, 2005 3.4 April 18, 2004 March 6, 2006 4.0 April 20, 2005 January 31, 2007 4.1 February 28, 2006 February 13, 2007 4.2 May 13, 2007May 19, 2008 4.3 March 5, 2008 Jun 27, 2011 4.4 April 21, 2009 March 13, 2012 4.5 April 14, 2010 Jul 2, 2012 4.6 March 25, 2011 April 12, 2013 4.7 March 22, 2012 - 4.8 March 22, 2013 - --- I personally think it's time to dump some older compiler versions, and adopt at least individual C99 features (e.g. static inlines). Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Unportable coding in reorderbuffer.h
On Wed, Mar 5, 2014 at 6:50 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-03-05 17:40:56 -0500, Tom Lane wrote:
I don't believe that this is legal per C90:
typedef struct ReorderBufferChange
{
XLogRecPtrlsn;
/* type of change */
union
{
enum ReorderBufferChangeType action;
/* do not leak internal enum values to the outside */
intaction_internal;
};
...
That union field needs a name.
You're absolutely right.
Our project standard is we compile on C90 compilers, and we're not
moving that goalpost just to save you a couple of keystrokes.
While it's a good idea to try to save keystrokes the actual reason is
that I just had somehow forgotten that it hasn't always been
supported. I think it's not even C99, but C11...
Urgh. I know that isn't per project style, but I just plain missed it
while staring at these patches. At one point I thought of complaining
that separating the public and private values was not a worthwhile
endeavor, but I don't think I ever did. Still, I agree with Tom's
suggestion of dumping the distinction.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Unportable coding in reorderbuffer.h
Andres Freund and...@2ndquadrant.com writes: On 2014-03-05 19:12:15 -0500, Tom Lane wrote: I'm surprised too; I had thought we still had some critters running hoary compilers. We need to do something about that if we actually believe in C90-compiler support. What version was the gcc that triggered the error? That was the 2.95.3 I have on my HPPA box. I don't have any 3.x versions in captivity; the next oldest I have is 4.0.1 on a Mac (running Leopard or thereabouts), and it seems to take this code. I have to admit that I am really not interested in supporting gcc 2.95 , that thing is just too old (nearly 15 years!) and buggy. [ shrug... ] In 15 years, the only problem I've seen with 2.95.3 is that it's prone to complaining about variables-clobbered-by-longjmp that no other compiler is unhappy with. Maybe the HPPA build is less buggy due to less aggressive optimization? I usually use -O1 with it, and that backend might be less tense than the Intel backend anyway. However, this is probably a bit beside the point. I'm quite prepared to believe that nobody uses gcc 4.0 anymore. The question is what older non-gcc compilers are still out there, and can we either get hold of them for the buildfarm, or trust that a really old gcc will complain about the same things they would? I suspect that most of the candidates would be proprietary compilers, so short of shelling out license fees I think we might be stuck with using old gcc as a proxy. As I said, I've more often than not found that things 2.95.3 will take don't cause problems elsewhere. I personally think it's time to dump some older compiler versions, and adopt at least individual C99 features (e.g. static inlines). Meh. In the first place, what you want is not C99 inlines it's GNU inlines; the standard's version is brain-dead. But I'm not prepared to declare us a GCC-only shop. In the second place, we already have a workable if slightly klugy solution for GNU inlines without assuming all compilers do that. I don't see a need to throw that overboard. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Unportable coding in reorderbuffer.h
On 2014-03-05 20:03:16 -0500, Tom Lane wrote: However, this is probably a bit beside the point. I'm quite prepared to believe that nobody uses gcc 4.0 anymore. The question is what older non-gcc compilers are still out there, and can we either get hold of them for the buildfarm, or trust that a really old gcc will complain about the same things they would? I suspect that most of the candidates would be proprietary compilers, so short of shelling out license fees I think we might be stuck with using old gcc as a proxy. I wonder if it makes sense to send out an -announce email asking for critters if they want $platform to stay supported. No response doesn't imply explicitly desupporting $platform... The channels where I recall request for critters on old platforms being made don't have a very high circulation (e.g. -bugs). I personally think it's time to dump some older compiler versions, and adopt at least individual C99 features (e.g. static inlines). Meh. In the first place, what you want is not C99 inlines it's GNU inlines; the standard's version is brain-dead. That's true for several inline variants (extern inline, inline without extern), but unless I am severely misremembering not for static inlines. And static inline is what I am interested in. But I'm not prepared to declare us a GCC-only shop. All platforms, even the hpux critter that existed till some time ago, do support static inline. It's only that the hpux critter warned about unused functions, but even that could have been disabled with a compiler flag. In the second place, we already have a workable if slightly klugy solution for GNU inlines without assuming all compilers do that. Meh squared. As the person first starting with the STATIC_IF_INLINE thing I am readily declaring it a utterly horrible crock. And not one suited for all things. I very much want to replace some of the uglier macros with inline functions. Some are very, very hard to understand and give utterly horrible error messages that are very hard to understand, even for experienced people. And several of those cannot be replaced by a extern function without indirectly making the respective non-static-inline-supporting platforms indirectly unsupported. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Unportable coding in reorderbuffer.h
On 2014-03-05 20:02:56 -0500, Robert Haas wrote: On Wed, Mar 5, 2014 at 6:50 PM, Andres Freund and...@2ndquadrant.com wrote: Urgh. I know that isn't per project style, but I just plain missed it while staring at these patches. At one point I thought of complaining that separating the public and private values was not a worthwhile endeavor, but I don't think I ever did. Still, I agree with Tom's suggestion of dumping the distinction. Ok, convinced, consider it dumped. Unless somebody protests I'll try to get the remaining walsender and docs patches ready before sending in the patch fixing this as it's not disturbing the buildfarm. I'll be onsite/travelling tomorrow; so I am not sure I'll be done then, but friday it is. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Documentation patch for date/time formatting functions
On Thu, Nov 7, 2013 at 11:46:24AM +0900, Michael Paquier wrote:
On Thu, Nov 7, 2013 at 9:14 AM, Steve Crawford
scrawf...@pinpointresearch.com wrote:
Due to a variety of messages over time regarding perceived weirdness in
to_timestamp and to_date, this patch adds (see notes) in the description
column for to_date and to_timestamp in the Formatting Functions table and
adds the following text to the opening of the usage notes for date/time
conversion:
The to_date and to_timestamp functions exist to handle unusual input formats
that cannot be converted by simple casting. These functions interpret input
liberally and with minimal error checking and while they will produce valid
output, the conversion has the potential to yield unexpected results. Read
the following notes and test carefully before use. Casting is the preferred
method of conversion wherever possible.
It also adds the following usage note:
Input to to_date and to_timestamp is not restricted to normal ranges thus
to_date('20096040','MMDD') returns 2014-01-17 rather than causing an
error.
This is the first patch I have submitted directly. Please advise if I have
made any errors in method, style, etc.
Sure. You should do the following things:
- attach a proper patch to the email you are sending such as people
can easily download it and have a look at it without having to
regenerate it themselves
- submit it to the next commit fest if you want to have it reviewed:
https://commitfest.postgresql.org/action/commitfest_view?id=20. Next
commit fest begins on the 15th of November and your patch is simple,
so for sure somebody will show up and have a closer look at it.
I have applied a modified version of your doc patch, attached. I didn't
bother with See below as everyone seems to find that section.
Thanks.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
new file mode 100644
index a1f627c..b1ea466
*** a/doc/src/sgml/func.sgml
--- b/doc/src/sgml/func.sgml
*** SELECT SUBSTRING('XY1234Z', 'Y*?([0-9]{1
*** 5785,5790
--- 5785,5804
listitem
para
+functionto_timestamp/function and functionto_date/function
+exist to handle input formats that cannot be converted by
+simple casting. These functions interpret input liberally,
+with minimal error checking. While they produce valid output,
+the conversion can yield unexpected results. For example,
+input to these functions is not restricted by normal ranges,
+thus literalto_date('20096040','MMDD')/literal returns
+literal2014-01-17/literal rather than causing an error.
+Casting does not have this behavior.
+ /para
+ /listitem
+
+ listitem
+ para
Ordinary text is allowed in functionto_char/function
templates and will be output literally. You can put a substring
in double quotes to force it to be interpreted as literal text
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Comment - uniqueness of relfilenode
On Mon, Nov 11, 2013 at 05:48:52PM +0100, Antonin Houska wrote: On 11/10/2013 12:57 AM, Robert Haas wrote: On Thu, Nov 7, 2013 at 10:56 AM, Antonin Houska antonin.hou...@gmail.com wrote: catalog/catalog.c:GetNewRelFileNode() and its calls indicate that the following change makes sense: diff --git a/src/include/storage/relfilenode.h b/src/include/storage/relfilenode.h index 75f897f..7190974 100644 --- a/src/include/storage/relfilenode.h +++ b/src/include/storage/relfilenode.h @@ -55,7 +55,7 @@ typedef enum ForkNumber * relNode identifies the specific relation. relNode corresponds to * pg_class.relfilenode (NOT pg_class.oid, because we need to be able * to assign new physical files to relations in some situations). - * Notice that relNode is only unique within a particular database. + * Notice that relNode is only unique within a particular tablespace. * * Note: spcNode must be GLOBALTABLESPACE_OID if and only if dbNode is * zero. We support shared relations only in the global tablespace. // Antonin Houska (Tony) Technically speaking, I think it's only guaranteed to be unique with a database-tablespace combination. In other words, the same OID can be reused as a relfilenode if *either* of those two values differs. You're right. I missed the fact that Postgres (unlike another DBMS that I worked with) allows for tablespace to be shared across databases. I have update the C comment: * Notice that relNode is only unique within a particular database. --- * Notice that relNode is only unique within a particular tablespace. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Row-security on updatable s.b. views
On 03/06/2014 04:56 AM, Yeb Havinga wrote: It might be an idea to add the SELECT RLS clause for DML queries that contain a RETURNING clause. That way lies madness: A DML statement that affects *a different set of rows* depending on whether or not it has a RETURNING clause. If you state it like that, it sounds like a POLA violation. But the complete story is: A user is allowed to UPDATE a set of rows from a table that is not a subsect of the set of rows he can SELECT from the table, iow he can UPDATE rows he is not allowed to SELECT. This can lead to unexpected results: When the user issues an UPDATE of the table without a returning clause, all rows the user may UPDATE are affected. When the user issues an UPDATE of the table with a returning clause, all rows the user may UPDATE and SELECT are affected. Well, I think that's bizarre behaviour. It doesn't make sense for RETURNING to affect the behaviour of the command it's applied to. It never has before, and it's defined to return the set of rows affected by the command. It shouldn't be changing that set, it isn't a predicate. So the madness comes from the fact that it is allowed to define RLS that allow to modify rows you cannot select. Either prevent these conditions (i.e. proof that all DML RLS qual implies the SELECT qual, otherwise give an error on DML with a RETURNING clause) Equivalence proofs in predicates are WAY outside what's going to be reasonable to tackle in a feature like this. Especially since the row security expression may be my_c_function(the_row), and all the detail of behaviour is hidden behind some C function. We need to treat row security expressions as pretty much opaque. or allow it without violating the RLS rules but accept that a DML with RETURNING is different from a DML only. I don't think that's acceptable. Too many tools automatically add a RETURNING clause, or use one in generated SQL. Notably, PgJDBC will append a RETURNING clause to your query so it can return generated keys. With regular permissions, we require that the user has SELECT rights if they use a RETURNING clause. That works because it's a simple permissions check. With row security, we'd be affecting a different set of rows instead, and doing so silently. That's just ugly. (It also creates execution inefficiencies where the SELECT and UPDATE/DELETE predicates are the same). Additionally, in PostgreSQL if you can supply a predicate for a row, you can leak the row via a RAISE NOTICE or other tricks. So even without RETURNING, allowing a user to update/delete a row permits them to potentially see the row. (This is an issue with our current permissions too; if you DELETE with a leaky predicate, you can see the rows you deleted even without SELECT rights on a table). That, IMO, is two good reasons not to differentiate between command types for the purpose of which rows they can see in a scan. We already have a mechanism for allowing users to do things that they can't normally do under controlled and restricted circumstances: SECURITY DEFINER functions. I don't think we need to introduce bizarre and surprising behaviour in DML when we have a viable mechanism for people who need to do this. Is there a compelling use case for this? Where it really makes sense to let users update/delete rows they cannot see via row security? We support it in the table based permissions model, but it's possible to do it with much saner semantics there. And with row security, it'll be possible with security definer functions. I intend to add a row security exempt flag for functions down the track, too. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GSoC on WAL-logging hash indexes
On Mon, Mar 3, 2014 at 4:12 PM, Robert Haas robertmh...@gmail.com wrote: Unfortunately, I don't believe that it's possible to do this easily today because of the way bucket splits are handled. I wrote about this previously here, with an idea for solving the problem: We could just tackle this in the same incomplete, buggy, way that btrees tackled it for years until Heikki fixed them and the way gin and gist still do I believe. Namely just emit xlog records for each page individually and during replay remember when you have an incomplete split and complain if recovery ends with any still incomplete. That would be unfortunate to be adding new cases of this just as Heikki and company are making progress eliminating the ones we already had but that's surely better than having no recovery at all. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] Negative Transition Aggregate Functions (WIP)
On Mar5, 2014, at 18:27 , Dean Rasheed dean.a.rash...@gmail.com wrote: On 5 March 2014 14:35, Florian Pflug f...@phlo.org wrote: When I added the EXPLAIN stuff, I initially simply reported the number of times nodeWindowAgg has to restart the aggregation. The problem with that approach is that not all restarts carry the same cost. If the frames either don't overlap at all or are identical, restarts don't cause any additional work. And for fixed-length frames (BETWEEN n PRECEEDING AND m FOLLOWING), the performance effects of restarts depends on m-n. Which is why I made it count the number of aggregated input rows instead. Having said that, I' not really 100% happy with the name Transitions Per Row for this - it was simply the best I could come up with that was reasonably short. And I'm certainly open to reporting the absolute count instead of a factor relative to ntuples. If we made it an absolute count, would calling this Aggregated Rows work for you? I'm not sure about naming, but I think my preference would be to output the correct absolute counts for both the forward and inverse transitions (i.e. multiply by the right combinations of numaggs and numaggs_restart). The EXPLAIN output already tells you how many aggregates there are, and how many rows there are, so you'd be able to work out from that how much extra work it's doing. Hm, if we do that we might as well go all the way and simply report these numbers per aggregate, instead of once per window aggregation node. That'd provide the maximum amount of information, and be quite unambiguous. best regards, Florian Pflug -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] BUG #9223: plperlu result memory leak
On Wed, Mar 5, 2014 at 12:55 PM, Alex Hunsaker bada...@gmail.com wrote: On Wed, Mar 5, 2014 at 12:22 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote: Can I bug you into verifying what supported releases need this patch, and to which does it backpatch cleanly? And if there's any to which it doesn't, can I further bug you into providing one that does? Sure! Not bugging at all. I'll dig into this in a few hours. This will apply cleanly all the way to REL9_2_STABLE. It applies (with fuzz, but cleanly to REL9_1). REL9_0 does this completely differently and so does not have this leak. Thanks! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Comment - uniqueness of relfilenode
On Wed, Mar 5, 2014 at 8:54 PM, Bruce Momjian br...@momjian.us wrote: On Mon, Nov 11, 2013 at 05:48:52PM +0100, Antonin Houska wrote: On 11/10/2013 12:57 AM, Robert Haas wrote: On Thu, Nov 7, 2013 at 10:56 AM, Antonin Houska antonin.hou...@gmail.com wrote: catalog/catalog.c:GetNewRelFileNode() and its calls indicate that the following change makes sense: diff --git a/src/include/storage/relfilenode.h b/src/include/storage/relfilenode.h index 75f897f..7190974 100644 --- a/src/include/storage/relfilenode.h +++ b/src/include/storage/relfilenode.h @@ -55,7 +55,7 @@ typedef enum ForkNumber * relNode identifies the specific relation. relNode corresponds to * pg_class.relfilenode (NOT pg_class.oid, because we need to be able * to assign new physical files to relations in some situations). - * Notice that relNode is only unique within a particular database. + * Notice that relNode is only unique within a particular tablespace. * * Note: spcNode must be GLOBALTABLESPACE_OID if and only if dbNode is * zero. We support shared relations only in the global tablespace. // Antonin Houska (Tony) Technically speaking, I think it's only guaranteed to be unique with a database-tablespace combination. In other words, the same OID can be reused as a relfilenode if *either* of those two values differs. You're right. I missed the fact that Postgres (unlike another DBMS that I worked with) allows for tablespace to be shared across databases. I have update the C comment: * Notice that relNode is only unique within a particular database. --- * Notice that relNode is only unique within a particular tablespace. Yep. But the new text is no more correct than the old text. Did you read what I wrote upthread? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Triggers on foreign tables
This version looks basically good. I have some cosmetic things to sweep up before commit. One point is a bit more substantial: On Tue, Feb 04, 2014 at 01:16:22PM +0100, Ronan Dunklau wrote: Le lundi 3 février 2014 23:28:45 Noah Misch a écrit : On Sun, Feb 02, 2014 at 11:53:51AM +0100, Ronan Dunklau wrote: We can remove ate_ptr2 and rely on the AFTER_TRIGGER_2CTIDS flag, but the rescanning and ate_ptr1 (renamed ate_tupleindex in the attached patch) can't go away. Consider for example the case of a foreign table with more than one AFTER UPDATE triggers. Unless we store the tuples once for each trigger, we will have to rescan the tuplestore. Will we? Within a given query level, when do (non-deferred) triggers execute in an order other than the enqueue order? Let me explain what I had in mind. Looking at the code in AfterTriggerSaveEvent: - we build a template AfterTriggerEvent, and store the tuple(s) - for each suitable after trigger that matches the trigger type, as well as the WHEN condition if any, a copy of the previously built AfterTriggerEvent is queued Later, those events are fired in order. This means that more than one event can be fired for one tuple. Take this example: [snip] Thanks; that illuminated the facts I was missing. On a side note, this made me realize that it is better to avoid storing a tuple entirely if there is no enabled trigger (the f1 = 4 case above). The attached patch does that, so the previous sequence becomes: 0-0-2-2-4-6-6 It also prevents from initalizing a tuplestore at all if its not needed. That's a sensible improvement. To mitigate the effects of this behaviour, I added the option to perform a reverse_seek when the looked-up tuple is nearer from the current index than from the start. If there's still a need to seek within the tuplestore, that should get rid of the O(n^2) effect. I'm hoping that per-query-level tuplestores will eliminate the need to seek entirely. I think the only case when seeking is still needed is when there are more than one after trigger that need to be fired, since the abovementioned change prevents from seeking to skip tuples. Agreed. More specifically, I see only two scenarios for retrieving tuples from the tuplestore. Scenario one is that we need the next tuple (or pair of tuples, depending on the TriggerEvent). Scenario two is that we need the tuple(s) most recently retrieved. If that's correct, I'm inclined to rearrange afterTriggerInvokeEvents() and AfterTriggerExecute() to remember the tuple or pair of tuples most recently retrieved. They'll then never call tuplestore_advance() just to reposition. Do you see a problem with that? I was again somewhat tempted to remove ate_tupleindex, perhaps by defining the four flag bits this way: #define AFTER_TRIGGER_DONE 0x1000 #define AFTER_TRIGGER_IN_PROGRESS 0x2000 /* two bits describing the size of and tuple sources for this event */ #define AFTER_TRIGGER_TUP_BITS 0xC000 #define AFTER_TRIGGER_FDW_REUSE 0x #define AFTER_TRIGGER_FDW_FETCH 0x4000 #define AFTER_TRIGGER_1CTID 0x8000 #define AFTER_TRIGGER_2CTID 0xC000 AFTER_TRIGGER_FDW_FETCH and AFTER_TRIGGER_FDW_REUSE correspond to the aforementioned scenarios one and two, respectively. I think, though, I'll rate this as needless micro-optimization and not bother; opinions welcome. (The savings is four bytes per foreign table trigger event.) Thanks, nm -- Noah Misch EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Securing make check (CVE-2014-0067)
On Tue, Mar 04, 2014 at 07:10:27PM -0500, Bruce Momjian wrote: On Sat, Mar 1, 2014 at 01:35:45PM -0500, Noah Misch wrote: Having that said, I can appreciate the value of tightening the socket mode for a bit of *extra* safety: --- a/src/test/regress/pg_regress.c +++ b/src/test/regress/pg_regress.c @@ -2299,4 +2299,5 @@ regression_main(int argc, char *argv[], init_function ifunc, test_function tfunc fputs(\n# Configuration added by pg_regress\n\n, pg_conf); fputs(max_prepared_transactions = 2\n, pg_conf); + fputs(unix_socket_permissions = 0700\n, pg_conf); Pg_upgrade has this exact same problem, and take the same approach. You might want to look in pg_upgrade/server.c. Thanks. To avoid socket path length limitations, I lean toward placing the socket temporary directory under /tmp rather than placing under the CWD: http://www.postgresql.org/message-id/flat/20121129223632.ga15...@tornado.leadboat.com -- Noah Misch EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: Custom Scan APIs (Re: [HACKERS] Custom Plan node)
Kouhei Kaigai kai...@ak.jp.nec.com writes:
* Please drop the whole register_custom_provider/get_custom_provider
API.
One thing I was worrying about is how copyObject() and nodeToString()
support set of function pointer tables around custom-scan node,
however, you suggested to change the assumption here. So, I think these
functions become unnecessary.
If we allow the extension to control copyObject behavior, it can do what
it likes with the function-struct pointer. I think the typical case would
be that it's a simple pointer to a never-copied static constant. But you
could imagine that it's a pointer to a struct embedded further down in the
custom path or plan node, if the extension wants different functions for
different plans.
If we had to support stringToNode() for paths or plans, things would get
much more complicated, but we don't (and there are already lots of other
things that would be difficult for that).
I expected to include simple function pointers for copying and text-output
as follows:
typedef struct {
Planplan;
:
NodeCopy_functionnode_copy;
NodeTextOut_function node_textout;
} Custom;
Then, sub-routine in copyfuncs.c shall be:
static Custom *
_copyCustom(const Custom *from)
{
return from-node_copy(from);
}
Can I share same image for this? It allows Custom node to have polymorphism
on the node it enhanced.
Sorry, I got little bit confused. Is the function-struct pointer you
mentioned something different from usual function pointer?
The reason why CustomScan is derived from Scan is, some of backend
code wants to know rtindex of the relation to be referenced by this
CustomScan.
The scanrelid of Scan is used in three points: nodeCustom.c, setrefs.c
and explain.c. The usage in nodeCustom.c is just for service routines,
and the usage in setrefs.c can be moved to the extension according to
your suggestion.
We need to investigate the usage in explain.c; ExplainPreScanNode()
walks around the nodes to collect relids referenced in this query. If
we don't want to put a callback for this specific usage, it is a
reasonable choice to show the backend the associated scanrelid of
CustomScan.
I think we have to add another callback for that :-(. It's a pain since
it's such a trivial point; but the existing code cannot support a custom
node referencing more than one RTE, which seems possible for join or append
type cases.
It's more generic approach, I like this.
Probably, it can kill the characteristic as Scan of CustomScan from the
view of core backend. It shall perform as an opaque Plan node that may
scan, join, sort or something, so more appropriate its name may be
CustomPlan or simply Custom.
Probably, the hunk around show_customscan_info() call can be entirely
moved to the extension side. If so, I want ExplainNode() being an
extern function, because it allows extensions to print underlying
plan-nodes.
I haven't looked at what explain.c would have to expose to make this workable,
but yeah, we will probably have to export a few things.
OK,
Are you saying the hard-wired portion in setrefs.c can be moved to the
extension side? If fix_scan_expr() become extern function, I think it
is feasible.
My recollection is that fix_scan_expr() is a bit specialized. Not sure
exactly what we'd have to export there --- but we'd have to do it anyway.
What you had in the patch was a hook that could be called, but no way for
it to do what it would likely need to do.
It probably needs to be exported. It walks on the supplied node tree and
eventually calls record_plan_function_dependency() for each functions being
found. It should not be invented in the extension again.
Anyway, my reworking on the patch will make clear which static functions
need to be exposed. Please wait for a while.
* Get rid of the CUSTOM_VAR business, too (including custom_tupdesc).
In case of Var-node that references joined-relations, it shall be
replaced to either INNER_VAR or OUTER_VAR according the location of
underlying relations. It eventually makes ExecEvalScalarVar() to
reference either ecxt_innertuple or ecxt_outertuple, however, it is
problematic if we already consolidated tuples come from the both side
into one.
So? If you did that, then you wouldn't have renumbered the Vars as
INNER/OUTER. I don't believe that CUSTOM_VAR is necessary at all; if it
is needed, then there would also be a need for an additional tuple slot
in executor contexts, which you haven't provided.
For example, the enhanced postgres_fdw fetches the result set of
remote join query, thus a tuple contains the fields come from both side.
In this case, what varno shall be suitable to put?
That would be a scan situation, and the vars could reference the scan tuple
slot. Which in fact was the implementation you were using, so how is
CUSTOM_VAR adding anything?
Let me sort out the points.
If
Re: [HACKERS] pg_ctl status with nonexistent data directory
On Thu, Mar 6, 2014 at 4:38 AM, Bruce Momjian br...@momjian.us wrote: On Mon, Nov 4, 2013 at 11:31:30AM -0500, Robert Haas wrote: On Sat, Nov 2, 2013 at 3:32 PM, Peter Eisentraut pete...@gmx.net wrote: This doesn't seem right: $ pg_ctl -D /nowhere status pg_ctl: no server running It does exit with status 3, so it's not all that broken, but I think the error message could be more accurate. I doubt anyone will object if you feel the urge to fix it. I won't, anyway. I have addressed this issue with the attached patch: $ pg_ctl -D /lkjasdf status pg_ctl: directory /lkjasdf does not exist $ pg_ctl -D / status pg_ctl: directory / is not a database cluster directory One odd question is that pg_ctl status has this comment for reporting the exit code for non-running servers: printf(_(%s: no server running\n), progname); /* * The Linux Standard Base Core Specification 3.1 says this should return * '3' * https://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html */ exit(3); If they haven't passed us a data directory, we don't really know if the server is running or not, so the patch just returns '1'. But for such cases, isn't the status 4 more appropriate? As per above link 4 program or service status is unknown status 1 - 1 program is dead and /var/run pid file exists Going by this definition, it seems status 1 means, someone has forcefully killed the server and pid file still remains. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
On Wed, Mar 5, 2014 at 11:32 AM, Bruce Momjian br...@momjian.us wrote: So, now knowing that hstore2 is just hierarchical hstore using the same hstore type name, you are saying that we are keeping the non-hierarchical code in contrib, and the rest goes into core --- that makes sense, and from a code maintenance perspective, I like that the non-hierarchical hstore code is not going in core. Yeah. It's hard to justify having a user-facing hstore2 on the grounds of backwards compatibility, and giving those stuck on hstore the benefit of all of these new capabilities. That's because we *cannot* really preserve compatibility, AFAICT. Many of the lines of the patch submitted are due to changes in the output format of hstore, and the need to update the hstore tests' expected results to reflect these changes. For example: *** select slice(hstore 'aa=1, b=2, c=3', *** 759,779 (1 row) select slice(hstore 'aa=1, b=2, c=3', ARRAY['c','b']); !slice ! ! b=2, c=3 (1 row) select slice(hstore 'aa=1, b=2, c=3', ARRAY['aa','b']); ! slice ! - ! b=2, aa=1 (1 row) select slice(hstore 'aa=1, b=2, c=3', ARRAY['c','b','aa']); ! slice ! --- ! b=2, c=3, aa=1 (1 row) select pg_column_size(slice(hstore 'aa=1, b=2, c=3', ARRAY['c','b'])) --- 777,797 (1 row) select slice(hstore 'aa=1, b=2, c=3', ARRAY['c','b']); ! slice ! ! b=2, c=3 (1 row) select slice(hstore 'aa=1, b=2, c=3', ARRAY['aa','b']); ! slice ! - ! b=2, aa=1 (1 row) select slice(hstore 'aa=1, b=2, c=3', ARRAY['c','b','aa']); ! slice ! - ! b=2, c=3, aa=1 (1 row) I could believe that there was at least something to be said for a user-visible hstore2 if the new capabilites were available without breaking application code, but it seems that isn't the case. Anyone who is going to have to deal with some of this kind of incompatibility one way or the other might as well switch over to jsonb entirely. When changing aspects of our output format like this, the impact on users is more or less a step function (of the number of small changes). -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] jsonb and nested hstore
On 03/05/2014 09:07 PM, Peter Geoghegan wrote: It's hard to justify having a user-facing hstore2 on the grounds of backwards compatibility, and giving those stuck on hstore the benefit of all of these new capabilities. That's because we *cannot* really preserve compatibility, AFAICT. Many of the lines of the patch submitted are due to changes in the output format of hstore, and the need to update the hstore tests' expected results to reflect these changes. For example: Thank you for checking that. Teodor's goal was that new-hstore be 100% backwards-compatible with old-hstore. If we're breaking APIs, then it doesn't really work to force users to upgrade the type, no? Teodor, are these output changes things that can be made consistent, or do we need separate hstore and hstore2 datatypes? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: Fwd: [HACKERS] patch: make_timestamp function
2014-03-05 16:22 GMT+01:00 Alvaro Herrera alvhe...@2ndquadrant.com: Pavel Stehule escribió: Hi I hope, so this patch fix it wtf? I tried to fix http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=f1ba94bcd9717b94b36868d6905547e313f3a359 Tom did it better than me. Regards Pavel -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services
Re: [HACKERS] Comment - uniqueness of relfilenode
On 03/06/2014 04:33 AM, Robert Haas wrote: On Wed, Mar 5, 2014 at 8:54 PM, Bruce Momjian br...@momjian.us wrote: On Mon, Nov 11, 2013 at 05:48:52PM +0100, Antonin Houska wrote: On 11/10/2013 12:57 AM, Robert Haas wrote: On Thu, Nov 7, 2013 at 10:56 AM, Antonin Houska antonin.hou...@gmail.com wrote: catalog/catalog.c:GetNewRelFileNode() and its calls indicate that the following change makes sense: diff --git a/src/include/storage/relfilenode.h b/src/include/storage/relfilenode.h index 75f897f..7190974 100644 --- a/src/include/storage/relfilenode.h +++ b/src/include/storage/relfilenode.h @@ -55,7 +55,7 @@ typedef enum ForkNumber * relNode identifies the specific relation. relNode corresponds to * pg_class.relfilenode (NOT pg_class.oid, because we need to be able * to assign new physical files to relations in some situations). - * Notice that relNode is only unique within a particular database. + * Notice that relNode is only unique within a particular tablespace. * * Note: spcNode must be GLOBALTABLESPACE_OID if and only if dbNode is * zero. We support shared relations only in the global tablespace. // Antonin Houska (Tony) Technically speaking, I think it's only guaranteed to be unique with a database-tablespace combination. In other words, the same OID can be reused as a relfilenode if *either* of those two values differs. You're right. I missed the fact that Postgres (unlike another DBMS that I worked with) allows for tablespace to be shared across databases. I have update the C comment: * Notice that relNode is only unique within a particular database. --- * Notice that relNode is only unique within a particular tablespace. Yep. But the new text is no more correct than the old text. Did you read what I wrote upthread? Perhaps ... unique within a particular (tablespace, database) combination. ? // Tony -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
