Re: [HACKERS] SCRAM protocol documentation

On 11/08/17 15:00, Michael Paquier wrote: On Fri, Aug 11, 2017 at 9:31 PM, Álvaro Hernández Tortosa wrote: On 11/08/17 13:18, Michael Paquier wrote: On Fri, Aug 11, 2017 at 3:50 PM, Álvaro Hernández Tortosa wrote: Relatedly, the SCRAM specification doesn't appear to allow omittin

Re: [HACKERS] SCRAM protocol documentation

On 11/08/17 13:18, Michael Paquier wrote: On Fri, Aug 11, 2017 at 3:50 PM, Álvaro Hernández Tortosa wrote: On 11/08/17 03:57, Peter Eisentraut wrote: The SCRAM protocol documentation (https://www.postgresql.org/docs/devel/static/sasl-authentication.html) states "To avoid confusion

Re: [HACKERS] SCRAM protocol documentation

the use of an empty username. If there's a clear meaning about ignoring the user here, why not settle on something like the "*"? It's not going to change the world sending a few bytes less on initialization, but I guess it doesn't hurt either... Álvaro

Re: [HACKERS] Authentication mechanisms categorization

On 14/07/17 13:29, Michael Paquier wrote: On Fri, Jul 14, 2017 at 12:16 PM, Álvaro Hernández Tortosa wrote: If the parameter authmethod would rather be "authmethods", i.e., a list, I think it would be significantly more flexible. Yes, but the handling of a list becomes messie

Re: [HACKERS] Authentication mechanisms categorization

On 14/07/17 11:09, Michael Paquier wrote: On Sat, Jul 8, 2017 at 2:19 PM, Álvaro Hernández Tortosa wrote: There has been some prior discussion, that we recently continued at pgday.ru, about what to do if a client wants to use a "strong" authentication mechanism but a ro

Re: [HACKERS] Authentification method on client side checking

? Any answer should also be coordinated among the drivers. Álvaro -- Álvaro Hernández Tortosa --- <8K>data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Authentication mechanisms categorization

t;safe" as SCRAM with our without channel binding? I believe this should be discussed and find a common agreement to be implemented by libpq and all the drivers, including a single naming scheme for the parameter and possible values. Opinions? Álvaro -- Álvaro Hernández Tortosa --

Re: [HACKERS] SCRAM auth and Pgpool-II

om a SCRAM protocol perspective, this is very simple, just an extra attribute. Part b) may need more discussion. I believe this could be of help to your case and other middleware. Álvaro -- Álvaro Hernández Tortosa --- <8K>data -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Using postgres planner as standalone component

code. Thanks! Maybe you'd like to consider gporca https://github.com/greenplum-db/gporca as an alternative. You may also want to look at Calcite https://calcite.apache.org/docs/ if you were more into the Java world. Álvaro -- Álvaro Hernández Tortosa --- <8K>

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

ed, I will work towards another patch to implement channel binding. Should be reasonably easy now, thanks to this. Appreciated! Álvaro -- Álvaro Hernández Tortosa --- <8K>data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make chan

Re: [HACKERS] SCRAM in the PG 10 release notes

it will be merged soon, and the list of drivers could then be updated with this. Álvaro -- Álvaro Hernández Tortosa --- <8K>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: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

if there are re-negotiations, it gets more complicated. Server-end-point is kind of better specified: " The hash of the TLS server's certificate [RFC5280] as it appears, octet for octet, in the server's Certificate message. " Álvaro -- Álvaro Hernández Tortosa --

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

other SSL implementations, then what? We can't change it later without breaking compatibility with our own prior implementation. Note that Álvaro Hernández Tortosa said about two hours before you sent this email that it doesn't seem possible to implement something comparable in Java&

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

ue. Both are equally safe and effective and so having support for both seems sensible to me. Álvaro -- Álvaro Hernández Tortosa --- <8K>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] Channel binding support for SCRAM-SHA-256

as been built with SSL support to the list. And I'd say the list of channel binding names supported. Álvaro -- Álvaro Hernández Tortosa --- <8K>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] Letting the client choose the protocol to use during a SASL exchange

35 PM, Álvaro Hernández Tortosa wrote: > >> On 13/04/17 13:24, Heikki Linnakangas wrote: >> >>> Right, when we get channel binding, the server will list >>> "SCRAM-SHA-256" and "SCRAM-SHA-256-PLUS" as the list of mechanisms. >>> And if we get c

Re: [HACKERS] Letting the client choose the protocol to use during a SASL exchange

On 13/04/17 04:54, Michael Paquier wrote: On Thu, Apr 13, 2017 at 6:37 AM, Álvaro Hernández Tortosa wrote: By looking at the them, and unless I'm missing something, I don't see how the extra information for the future implementation of channel binding would be added (withou

Re: [HACKERS] Letting the client choose the protocol to use during a SASL exchange

On 13/04/17 13:24, Heikki Linnakangas wrote: On 04/13/2017 05:54 AM, Michael Paquier wrote: On Thu, Apr 13, 2017 at 6:37 AM, Álvaro Hernández Tortosa wrote: By looking at the them, and unless I'm missing something, I don't see how the extra information for the future impleme

Re: [HACKERS] Letting the client choose the protocol to use during a SASL exchange

On 12/04/17 19:34, Heikki Linnakangas wrote: On 04/11/2017 02:32 PM, Álvaro Hernández Tortosa wrote: So I still see your proposal more awkward and less clear, mixing things that are separate. But again, your choice :) So, here's my more full-fledged proposal. The first

Re: [HACKERS] Some thoughts about SCRAM implementation

On 12/04/17 18:38, Robert Haas wrote: On Tue, Apr 11, 2017 at 9:20 AM, Álvaro Hernández Tortosa wrote: LOL. Do you really want a half-baked Java programmer writing a patch in C for PostgreSQL? I once tried that and Magnus said my code was Java code that happened to compile with a C

Re: [HACKERS] Some thoughts about SCRAM implementation

Doesn't sound terribly friendly. A report of a certificate mismatch is far more likely to lead people to realize there's a MITM. So given what I said before, that won't happen. Indeed, SCRAM RFC contains a specific error code for this: "channel-bindings-do

Re: [HACKERS] Some thoughts about SCRAM implementation

On 11/04/17 15:18, Heikki Linnakangas wrote: On 04/11/2017 04:09 PM, Álvaro Hernández Tortosa wrote: But I will conserve my remaining courage (thanks Michael!) credits for future threads ;) I have stated my opinion clearly, I will now go back to the client library. Once you're

Re: [HACKERS] Some thoughts about SCRAM implementation

On 11/04/17 15:03, Magnus Hagander wrote: On Tue, Apr 11, 2017 at 2:53 PM, Álvaro Hernández Tortosa mailto:a...@8kdata.com>> wrote: On 10/04/17 20:32, Andres Freund wrote: On 2017-04-10 20:28:27 +0200, Álvaro Hernández Tortosa wrote: On 10/04/17 13:02,

Re: [HACKERS] Some thoughts about SCRAM implementation

On 10/04/17 20:32, Andres Freund wrote: On 2017-04-10 20:28:27 +0200, Álvaro Hernández Tortosa wrote: On 10/04/17 13:02, Heikki Linnakangas wrote: On 04/10/2017 12:39 PM, Álvaro Hernández Tortosa wrote: - I think channel binding support should be added. SCRAM brings security improvements

Re: [HACKERS] Letting the client choose the protocol to use during a SASL exchange

On 11/04/17 13:21, Heikki Linnakangas wrote: On 04/11/2017 01:39 PM, Álvaro Hernández Tortosa wrote: The fact that you null terminate them (fine with me) doesn't change my reasoning. How do you separate multiple channel binding methods? And do you realize that you will be repeatin

Re: [HACKERS] Letting the client choose the protocol to use during a SASL exchange

On 11/04/17 12:23, Heikki Linnakangas wrote: On 04/11/2017 11:55 AM, Álvaro Hernández Tortosa wrote: On 11/04/17 08:50, Heikki Linnakangas wrote: Oh, I see. According to the SCRAM RFC, "tls-unique" is used by default. I don't see us implementing anything else any time s

Re: [HACKERS] Letting the client choose the protocol to use during a SASL exchange

On 11/04/17 08:50, Heikki Linnakangas wrote: On 04/10/2017 11:03 PM, Álvaro Hernández Tortosa wrote: Channel binding needs to specify actually three things: - The mechanism, which is indeed suffixed "-PLUS". - The channel binding name, which is described here: https://tools.iet

Re: [HACKERS] Letting the client choose the protocol to use during a SASL exchange

On 10/04/17 21:41, Heikki Linnakangas wrote: On 04/10/2017 09:33 PM, Álvaro Hernández Tortosa wrote: Thanks for posting the patched HTML. In my opinion, all looks good except that: - I will add an extra String (a CSV) to AuthenticationSASL message for channel binding names, so that

Re: [HACKERS] Letting the client choose the protocol to use during a SASL exchange

On 10/04/17 14:57, Heikki Linnakangas wrote: On 04/07/2017 01:13 AM, Michael Paquier wrote: On Fri, Apr 7, 2017 at 5:15 AM, Álvaro Hernández Tortosa wrote: I don't see it. The message AuthenticationSASL.String could contain a CSV of the SCRAM protocols supported. This is spec

Re: [HACKERS] Some thoughts about SCRAM implementation

On 10/04/17 13:02, Heikki Linnakangas wrote: On 04/10/2017 12:39 PM, Álvaro Hernández Tortosa wrote: - I think channel binding support should be added. SCRAM brings security improvements over md5 and other simpler digest algorithms. But where it really shines is together with channel binding

[HACKERS] Some thoughts about SCRAM implementation

rd, and also proceed until the last stage even if errors were detected earlier (to conform with the RFC). Thoughts? Álvaro -- Álvaro Hernández Tortosa --- <8K>data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Some thoughts about SCRAM implementation

rd, and also proceed until the last stage even if errors were detected earlier (to conform with the RFC). Thoughts? Álvaro -- Álvaro Hernández Tortosa --- <8K>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] SCRAM authentication, take three

and would definitely make it explicit. As for the options, there's no way to negotiate, the client picks. It could still be three-valued: on, off, only-channel-binding (or however you want to call them). That will only change what mechanisms the server will be advertising to clients. Álvaro -- Álvaro Hernández Tortosa --- <8K>data

Re: [HACKERS] Letting the client choose the protocol to use during a SASL exchange

cket) a list of auth protocols it thinks it is able to handle. Per the SCRAM RFC, it is the server who advertises and the client who picks. Regards, Álvaro -- Álvaro Hernández Tortosa --- <8K>data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgres

Re: [HACKERS] Re: Letting the client choose the protocol to use during a SASL exchange

could be wrong, of course. I'm working myself on Java's (pgjdbc) implementation, and I will hopefully have a prototype by next week to try it. Álvaro -- Álvaro Hernández Tortosa --- <8K>data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgre

Re: [HACKERS] Implementing full UTF-8 support (aka supporting 0x00)

On 03/08/16 21:42, Geoff Winkless wrote: On 3 August 2016 at 20:36, Álvaro Hernández Tortosa wrote: Isn't the correct syntax something like: select E'\uc080', U&'\c080'; ? It is a single character, 16 bit unicode sequence (see https://www.postgresq

Re: [HACKERS] Implementing full UTF-8 support (aka supporting 0x00)

On 03/08/16 21:31, Geoff Winkless wrote: On 3 August 2016 at 20:13, Álvaro Hernández Tortosa wrote: Yet they are accepted by Postgres (like if Postgres would support Modified UTF-8 intentionally). The caracter in psql does not render as a nul but as this symbol: "삀". Not accepte

Re: [HACKERS] Implementing full UTF-8 support (aka supporting 0x00)

On 03/08/16 20:14, Álvaro Hernández Tortosa wrote: On 03/08/16 17:47, Kevin Grittner wrote: On Wed, Aug 3, 2016 at 9:54 AM, Álvaro Hernández Tortosa wrote: What would it take to support it? Would it be of any value to support "Modified UTF-8"? https://en.wikipedia.org/

Re: [HACKERS] Implementing full UTF-8 support (aka supporting 0x00)

On 03/08/16 18:35, Geoff Winkless wrote: On 3 August 2016 at 15:54, Álvaro Hernández Tortosa wrote: Given that 0x00 is a perfectly legal UTF-8 character, I conclude we're strictly non-compliant. It's perhaps worth mentioning that 0x00 is valid ASCII too, and PostgreSQL has ne

Re: [HACKERS] Implementing full UTF-8 support (aka supporting 0x00)

On 03/08/16 17:47, Kevin Grittner wrote: On Wed, Aug 3, 2016 at 9:54 AM, Álvaro Hernández Tortosa wrote: What would it take to support it? Would it be of any value to support "Modified UTF-8"? https://en.wikipedia.org/wiki/UTF-8#Modified_UTF-8 That's nice, bu

Re: [HACKERS] Implementing full UTF-8 support (aka supporting 0x00)

implementing a new datatype based on bytea but that would use the text IO functions to show up as text (not send/recv) would neither work, right? Thanks for the input, Álvaro -- Álvaro Hernández Tortosa --- 8Kdata -- Sent via pgsql-hackers mailing list (pgsql-hackers

[HACKERS] Implementing full UTF-8 support (aka supporting 0x00)

ch is very expensive, or dropping data). What would it take to support it? Isn't the varlena header propagated everywhere, which could help infer the real length of the string? Any pointers or suggestions would be welcome. Thanks, Álvaro -- Álvaro Hernández Tortosa ---

Re: [HACKERS] Protocol buffer support for Postgres

erialization formats that might be worth considering. Not too long ago I suggested working specifically on serialization formas for the json/jsonb types: https://www.postgresql.org/message-id/56CB8A62.40100%408kdata.com I believe this effort is on the same boat. Álvaro -- Álva

Re: [HACKERS] 10.0

On 15/05/16 14:42, Magnus Hagander wrote: On Sun, May 15, 2016 at 2:29 PM, Álvaro Hernández Tortosa mailto:a...@8kdata.com>> wrote: On 14/05/16 20:02, Petr Jelinek wrote: +1 for going with 10.0 after 9.6 and 11.0 afterwards, etc. It will hopefully both end

Re: [HACKERS] 10.0

worse: I've been told that a company was using "PostgreSQL 8.5" ^_^ Álvaro -- Álvaro Hernández Tortosa --- 8Kdata -- 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] 10.0

forums like saying: "10.0 will come with amazing features, because version is bumped from 9.6". So +1 to call 10.0 the next version and 11.0 the one after that. Álvaro -- Álvaro Hernández Tortosa --- 8Kdata -- Sent via pgsql-hackers mailing list (pgsql-hacker

Re: [HACKERS] about google summer of code 2016

On 23/03/16 01:56, Amit Langote wrote: On 2016/03/23 9:19, Álvaro Hernández Tortosa wrote: - Regarding GSoC: it looks to me that we failed to submit in time. Is this what happened, or we weren't selected? If the former (and no criticism here, just realizing a fact) what can we do next ye

Re: [HACKERS] about google summer of code 2016

On 22/02/16 23:23, Álvaro Hernández Tortosa wrote: On 22/02/16 05:10, Tom Lane wrote: Heikki Linnakangas writes: On 19/02/16 10:10, Ã�lvaro Hernández Tortosa wrote: Oleg and I discussed recently that a really good addition to a GSoC item would be to study whether it's convenient to

Re: [HACKERS] Soliciting Feedback on Improving Server-Side Programming Documentation

point of an "API". Regards, Álvaro -- Álvaro Hernández Tortosa --- 8Kdata On 15/03/16 13:02, Corey Huinker wrote: Over the past few months, I've been familiarizing myself with postgres server side programming in C. My attempts to educate myself were s

Re: [HACKERS] New competition from Microsoft?

Absolutely, competition is very welcome! Álvaro -- Álvaro Hernández Tortosa --- 8Kdata -- 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] How can we expand PostgreSQL ecosystem?

me of them are explained here: https://aphyr.com/posts/327-jepsen-mariadb-galera-cluster Regards, Álvaro -- Álvaro Hernández Tortosa --- 8Kdata -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.post

Re: [HACKERS] PostgreSQL extension API? Documentation?

the API. If anyone could help me here, please let me know. Álvaro -- Álvaro Hernández Tortosa --- 8Kdata -- 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] PostgreSQL extension API? Documentation?

On 27/02/16 15:10, Chapman Flack wrote: On 02/27/16 08:37, Álvaro Hernández Tortosa wrote: In other words: what is the API surface exposed by PostgreSQL to extension developers? The assumption is that no PostgreSQL code should be modified, just adding your own and calling existing

Re: [HACKERS] PostgreSQL extension API? Documentation?

On 27/02/16 15:01, Fabrízio de Royes Mello wrote: On Sat, Feb 27, 2016 at 10:37 AM, Álvaro Hernández Tortosa mailto:a...@8kdata.com>> wrote: > > > Hi. > > I have a newbie question for extension development. Extensions provide an entry point, and are

[HACKERS] PostgreSQL extension API? Documentation?

hat is the API surface exposed by PostgreSQL to extension developers? The assumption is that no PostgreSQL code should be modified, just adding your own and calling existing funcitons. Thanks, Álvaro -- Álvaro Hernández Tortosa --- 8Kdata -- Sent via pgsql-hackers mailing l

Re: [HACKERS] The plan for FDW-based sharding

d. Academical approaches are sometimes "very academical", but studying them doesn't hurt either :) Álvaro -- Álvaro Hernández Tortosa --- 8Kdata -- 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] about google summer of code 2016

part from the chosen format, others may be provided as an alternative using different data formats. Or alternatives (like compressed text json). Of course, this may be better suited for a next GSoC project, of course. Álvaro -- Álvaro Hernández Tortosa --- 8Kdata -- Se

Re: [HACKERS] about google summer of code 2016

s less of the success condition that's not under the GSoC student's control. Agreed :) Álvaro -- Álvaro Hernández Tortosa --- 8Kdata -- 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] about google summer of code 2016

On 21/02/16 21:15, Heikki Linnakangas wrote: On 19/02/16 10:10, Álvaro Hernández Tortosa wrote: Oleg and I discussed recently that a really good addition to a GSoC item would be to study whether it's convenient to have a binary serialization format for jsonb over the wire. Some

Re: [HACKERS] about google summer of code 2016

hanks, Álvaro -- Álvaro Hernández Tortosa --- 8Kdata On 17/02/16 08:40, Amit Langote wrote: Hi Shubham, On 2016/02/17 16:27, Shubham Barai wrote: Hello everyone, I am currently pursuing my bachelor of engineering in computer science at Maharashtra Institute of Technology, Pune ,Ind

Re: [HACKERS] bugs and bug tracking

nothing else to add :) Best, Álvaro -- Álvaro Hernández Tortosa --- 8Kdata -- 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 and bug tracking

On 13/10/15 16:24, Andres Freund wrote: On 2015-10-13 16:21:54 +0200, Álvaro Hernández Tortosa wrote: On 13/10/15 04:40, Tom Lane wrote: I'm with Robert on the idea that commit log entries need to be limited-width. I personally format them to 75 characters, so that git_changelog's

Re: [HACKERS] bugs and bug tracking

ummary, 72 chars line wrapping) Álvaro -- Álvaro Hernández Tortosa --- 8Kdata -- 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] Fwd: [GENERAL] 4B row limit for CLOB tables

On 25/04/15 06:39, Jim Nasby wrote: On 4/24/15 7:11 PM, Álvaro Hernández Tortosa wrote: On 24/04/15 05:24, Tom Lane wrote: ... TBH, I've got very little enthusiasm for fixing this given the number of reports of trouble from the field, which so far as I recall is zero. Álvaro's ca

Re: [HACKERS] Fwd: [GENERAL] 4B row limit for CLOB tables

On 24/04/15 05:24, Tom Lane wrote: Stephen Frost writes: * Bruce Momjian (br...@momjian.us) wrote: On Sun, Feb 1, 2015 at 03:54:03PM +0100, Álvaro Hernández Tortosa wrote: The problem here is that performance degrades exponentially, or worse. Speaking here from experience, we already

Re: [HACKERS] Repeatable read and serializable transactions see data committed after tx start

On 24/03/15 20:56, Bruce Momjian wrote: On Fri, Mar 20, 2015 at 04:43:42PM -0400, Bruce Momjian wrote: On Sat, Nov 8, 2014 at 09:53:18PM +0100, Álvaro Hernández Tortosa wrote: On 07/11/14 22:02, Greg Sabino Mullane wrote: Kevin Grittner wrote: I think most people have always assumed that

Re: [HACKERS] reducing our reliance on MD5

On 11/02/15 02:30, Tom Lane wrote: [...] I think it would be wise to take two steps back and think about what the threat model is here, and what we actually need to improve. Offhand I can remember two distinct things we might wish to have more protection against: * scraping of passwords off t

Re: [HACKERS] Fwd: [GENERAL] 4B row limit for CLOB tables

to a few per second and then to a few per day. In the graphs you can't even realize there were more tables been created. At around 8K tables from the theoretical limit of 4B oids consumed, the process basically stopped (doing more insertions). Hope that this information helps.

Re: [HACKERS] Commitfest problems

QL community should be able to raise, globally, some millions per year to stably, and permanently, fund this community-guided development and have our best developers devoted 100% to PostgreSQL. Regards, Álvaro -- Álvaro Hernández Tortosa --- 8Kdata -- Sent via pgsql-hacke

Re: [HACKERS] Repeatable read and serializable transactions see data committed after tx start

On 07/11/14 22:02, Greg Sabino Mullane wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Kevin Grittner wrote: I think most people have always assumed that BEGIN starts the transaction and that is the point at which the snapshot is obtained. But there is so much evidence to the contr

Re: [HACKERS] Repeatable read and serializable transactions see data committed after tx start

On 06/11/14 15:00, Kevin Grittner wrote: Álvaro Hernández Tortosa wrote: There has been two comments which seem to state that changing this may introduce some performance problems and some limitations when you need to take out some locks. I still believe, however, that current behavior

Re: [HACKERS] Repeatable read and serializable transactions see data committed after tx start

On 06/11/14 02:06, Jim Nasby wrote: On 11/5/14, 6:04 PM, Álvaro Hernández Tortosa wrote: On 05/11/14 17:46, Jim Nasby wrote: On 11/4/14, 6:11 PM, Álvaro Hernández Tortosa wrote: Should we improve then the docs stating this more clearly? Any objection to do this? If we go that route

Re: [HACKERS] Repeatable read and serializable transactions see data committed after tx start

On 06/11/14 00:42, Robert Haas wrote: On Mon, Nov 3, 2014 at 2:14 PM, Álvaro Hernández Tortosa wrote: Given a transaction started with "BEGIN (REPEATABLE READ | SERIALIZABLE)", if a concurrent session commits some data before *any* query within the first transaction, that

Re: [HACKERS] Repeatable read and serializable transactions see data committed after tx start

On 05/11/14 17:46, Jim Nasby wrote: On 11/4/14, 6:11 PM, Álvaro Hernández Tortosa wrote: Should we improve then the docs stating this more clearly? Any objection to do this? If we go that route we should also mention that now() will no longer be doing what you probably hope it would

Re: [HACKERS] Repeatable read and serializable transactions see data committed after tx start

On 04/11/14 09:07, Craig Ringer wrote: On 11/04/2014 07:31 AM, Álvaro Hernández Tortosa wrote: Thank you for your comment, Tom. However I think this behavior, as seen from a user perspective, it's not the expected one. That may be the case, but I think it's the SQL-standard beh

Re: [HACKERS] Repeatable read and serializable transactions see data committed after tx start

not the real behavior. I think there are some examples in the "concurrency control" chapter of the manual. Sure, there are, that was the link I pointed out, but I found no explicit mention to the fact that I'm raising here. Regards, Álvaro -- Álvaro Hernández Torto

[HACKERS] Repeatable read and serializable transactions see data committed after tx start

, as it should, the same as the previous query In the first select, I'd have expected to have no rows. If a "SELECT 1" is issued after BEGIN, there are no rows found. -- Álvaro Hernández Tortosa --- 8Kdata

Re: [HACKERS] PL/pgSQL 2

On 04/09/14 18:02, Craig Ringer wrote: On 09/04/2014 06:48 AM, Joshua D. Drake wrote: On 09/03/2014 11:48 AM, Robert Haas wrote: Anyway, to get back around to the topic of PL/SQL compatibility specifically, if you care about that issue, pick one thing that exists in PL/SQL but not in PL/pgsql

Re: [HACKERS] PL/pgSQL 2

On 03/09/14 20:48, Robert Haas wrote: On Tue, Sep 2, 2014 at 5:47 PM, Álvaro Hernández Tortosa wrote: Yeah, we differ there. I think having an Oracle compatibility layer in PostgreSQL would be the-next-big-thing we could have. Oracle is has orders of magnitude bigger user base than

Re: [HACKERS] PL/pgSQL 2

On 03/09/14 15:24, Joshua D. Drake wrote: On 09/02/2014 04:01 PM, Álvaro Hernández Tortosa wrote: It's not copying. It's easying a path for others to migrate and come to Postgres. I'm interested why you are more interested in MSSQL. My reasons for being intereste

Re: [HACKERS] Tips/advice for implementing integrated RESTful HTTP API

On 02/09/14 04:47, Dobes Vandermeer wrote: Same idea as PgBouncer or PgPool. The advantage over hacking PgBouncer/PgPool for the job is that Tomcat can already do a lot of what you want using built-in, pre-existing functionality. Connection pool management, low level REST-st

Re: [HACKERS] PL/pgSQL 2

On 03/09/14 00:41, Joshua D. Drake wrote: On 09/02/2014 02:47 PM, Álvaro Hernández Tortosa wrote: Yeah, we differ there. I think having an Oracle compatibility layer in PostgreSQL would be the-next-big-thing we could have. Oracle is has orders of magnitude bigger user base than postgres

Re: [HACKERS] PL/pgSQL 2

On 02/09/14 23:34, Joshua D. Drake wrote: On 09/02/2014 02:11 PM, David Johnston wrote: On Tue, Sep 2, 2014 at 4:48 PM, Joshua D. Drake mailto:j...@commandprompt.com>>wrote: On 09/02/2014 09:48 AM, Bruce Momjian wrote: As a case in point, EDB have spent quite a few man-years

Re: [HACKERS] PL/pgSQL 2

On 02/09/14 23:11, David Johnston wrote: On Tue, Sep 2, 2014 at 4:48 PM, Joshua D. Drake >wrote: On 09/02/2014 09:48 AM, Bruce Momjian wrote: As a case in point, EDB have spent quite a few man-years on their Oracle compati

Re: [HACKERS] PL/pgSQL 2

On 02/09/14 18:33, Hannu Krosing wrote: On 09/02/2014 06:27 PM, Joel Jacobson wrote: On Tue, Sep 2, 2014 at 6:11 PM, Álvaro Hernández Tortosa wrote: We are definitely worse. This is the problem, we only look to our own belly bottom (if this expression exists in English). All NoSQL scale

Re: [HACKERS] PL/pgSQL 2

On 02/09/14 18:20, Joel Jacobson wrote: On Tue, Sep 2, 2014 at 6:09 PM, Kevin Grittner wrote: Joel Jacobson wrote: Sorry for being unclear, I didn't mean to suggest the main concern is updating *all* rows. The main concern is when you have a rather complex UPDATE WHERE clause, aiming to upd

Re: [HACKERS] PL/pgSQL 2

On 02/09/14 17:03, Hannu Krosing wrote: On 09/02/2014 11:52 AM, Álvaro Hernández Tortosa wrote: On 02/09/14 11:44, Pavel Stehule wrote: For 9.4, we have the media already saying "Postgres has NoSQL capabilities" (which is only partially true). For x.y we coul

Re: [HACKERS] PL/pgSQL 2

On 02/09/14 12:46, Marko Tiikkaja wrote: On 9/2/14 11:40 AM, Álvaro Hernández Tortosa wrote: If we are to have another plpgsql-like language (like plpgsql2) and we could design it so it would attract many many users (let's not forget that Oracle may have around two orders of magn

Re: [HACKERS] PL/pgSQL 2

On 02/09/14 11:56, Pavel Stehule wrote: 2014-09-02 11:50 GMT+02:00 Álvaro Hernández Tortosa <mailto:a...@nosys.es>>: On 02/09/14 11:31, Pavel Stehule wrote: 2014-09-02 11:25 GMT+02:00 Álvaro Hernández Tortosa mailto:a...@nosys.es>>: On 02/09/14 05:2

Re: [HACKERS] PL/pgSQL 2

On 02/09/14 11:44, Pavel Stehule wrote: For 9.4, we have the media already saying "Postgres has NoSQL capabilities" (which is only partially true). For x.y we could have the media saying "Postgres adds Oracle compatibility" (which would be only partially true). But that

Re: [HACKERS] PL/pgSQL 2

On 02/09/14 11:31, Pavel Stehule wrote: 2014-09-02 11:25 GMT+02:00 Álvaro Hernández Tortosa <mailto:a...@nosys.es>>: On 02/09/14 05:24, Craig Ringer wrote: I couldn't disagree more. If we were to implement anything, it'd be PL/PSM (http

Re: [HACKERS] PL/pgSQL 2

On 02/09/14 11:34, Mark Kirkwood wrote: On 02/09/14 21:25, Álvaro Hernández Tortosa wrote: On 02/09/14 05:24, Craig Ringer wrote: I couldn't disagree more. If we were to implement anything, it'd be PL/PSM (http://en.wikipedia.org/wiki/SQL/PSM). I'm sure it's as b

Re: [HACKERS] PL/pgSQL 2

On 02/09/14 06:40, Tom Lane wrote: Craig Ringer writes: If someone came up with a convincing PL/SQL compatibility layer then it'd be worth considering adopting - when it was ready. But of course, anyone who does the work for that is quite likely to want to sell it to cashed-up Oracle users loo

Re: [HACKERS] PL/pgSQL 2

On 02/09/14 05:24, Craig Ringer wrote: I couldn't disagree more. If we were to implement anything, it'd be PL/PSM (http://en.wikipedia.org/wiki/SQL/PSM). I'm sure it's as bizarre and quirky as anything else the SQL committee has brought forth, but it's at least a standard(ish) language. So

Re: [HACKERS] PL/pgSQL 2

On 01/09/14 23:46, David G Johnston wrote: Álvaro Hernández Tortosa wrote On 01/09/14 21:52, Joel Jacobson wrote: On Mon, Sep 1, 2014 at 8:34 PM, Álvaro Hernández Tortosa < aht@ > wrote: What I can add is that, if Postgres is to devote resources to a new language, I would plan i

Re: [HACKERS] PL/pgSQL 2

On 01/09/14 23:31, Marko Tiikkaja wrote: On 2014-09-01 11:11 PM, Álvaro Hernández Tortosa wrote: No, really: if there is a new version of a "language", which modifies the current syntax of plpgsql; if plpgsql is already very similar to PL/SQL: why not rather than coming up

Re: [HACKERS] PL/pgSQL 2

On 01/09/14 21:52, Joel Jacobson wrote: On Mon, Sep 1, 2014 at 8:34 PM, Álvaro Hernández Tortosa wrote: What I can add is that, if Postgres is to devote resources to a new language, I would plan it with a broader scope. What would attract most users? Would it bring non postgres users to

Re: [HACKERS] PL/pgSQL 2

On 01/09/14 21:08, Pavel Stehule wrote: 2014-09-01 20:58 GMT+02:00 Álvaro Hernández Tortosa <mailto:a...@nosys.es>>: On 01/09/14 20:42, Tom Lane wrote: =?UTF-8?B?w4FsdmFybyBIZXJuw6FuZGV6IFRvcnRvc2E=?= mailto:a...@nosys.es>> writes: What I

Re: [HACKERS] PL/pgSQL 2

On 01/09/14 20:42, Tom Lane wrote: =?UTF-8?B?w4FsdmFybyBIZXJuw6FuZGV6IFRvcnRvc2E=?= writes: What I can add is that, if Postgres is to devote resources to a new language, I would plan it with a broader scope. What would attract most users? Would it bring non postgres users to Postgres? Wh

Re: [HACKERS] PL/pgSQL 2

On 01/09/14 14:27, Joel Jacobson wrote: On Mon, Sep 1, 2014 at 1:30 PM, Pavel Stehule wrote: I agree with Andres - it is not a good for plpgsql and for plpgsql users. The benefit must be significant for 90% of users. ... Official implementation of plpgsql2 can be very wrong and dangerous sig

  1   2   >