> As I was saying, the queries were designed in such a way that even
> unprivileged user can run them (the results will be limited to the stats
> data available to that user, obviously; and for custom-tailored statstarget
> one still needs superuser to join the pg_statistic table directly)
On Wed, Mar 9, 2016 at 1:25 AM, Shulgin, Oleksandr
wrote:
> Thank you for spending your time to run these :-)
n/p, it took like 30 seconds :-)
> I don't want to be asking for too much here, but is there a chance you could
> try the effects of the proposed patch on an offline copy of your databas
On Mon, Dec 14, 2015 at 10:27 AM, Tom Lane wrote:
> Corey Huinker writes:
>> So, I'd propose we following syntax:
>> ALTER INDEX foo SET DISABLED
>> -- does the SET indisvalid = false shown earlier.
>
> This is exactly *not* what Tatsuo-san was after, though; he was asking
> for a session-local d
uthor: Joel Jacobson
Date: Fri Mar 11 08:19:52 2016 +0700
Make Have_Queries_Waiting() work with both <9.6 and >=9.6.
Apparently pg_stat_activity.waiting was removed by this commit:
commit 53be0b1add7064ca5db3cd884302dfc3268d884e
Author: Robert Haas
Date: Thu Mar
On Fri, Mar 11, 2016 at 9:36 AM, Robert Haas wrote:
> Well, this was discussed. If we keep the Boolean "waiting" column, then
> either:
Oh, sorry for missing out on that discussion.
> 1. We make it true only for heavyweight lock waits, and false for
> other kinds of waits. That's pretty stran
On Fri, Mar 11, 2016 at 11:14 AM, Robert Haas wrote:
> I'm not direly opposed to most of what's on that page,
> but I'm not excited about most of it, either.
May I ask, what improvements of PL/pgSQL would you personally be most
excited about,
if you or someone else would have unlimited resources
On Sat, Mar 12, 2016 at 4:08 AM, Robert Haas wrote:
>
> I don't think my experience in this area is as deep as you seem to
> think. I can tell you that most of the requests EnterpriseDB gets for
> PL/pgsql enhancements involve wanting it to be more like Oracle's
> PL/SQL, which of course has very
On Sat, Mar 12, 2016 at 4:41 AM, Pavel Stehule wrote:
> I afraid so you try to look on your use case as global/generic issue. The
> PL/SQL, ADA. PL/pgSQL are verbose languages, and too shortcuts does the
> languages dirty. In this point we have different opinion.
>
> I proposed some enhanced PLpgS
On Sat, Mar 12, 2016 at 4:48 AM, Joel Jacobson wrote:
> neither you nor me have nothing to add.
Correction: neither you nor me have anything to add.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailp
On Sat, Mar 12, 2016 at 5:09 AM, Pavel Stehule wrote:
>> What we need is more input on proposed changes from other companies
>> who are also heavy users of PL/pgSQL.
>>
>> Only then can we move forward. It's like Robert is saying, there is a
>> risk for bikeshedding here,
>> we must widen our pers
On Sat, Mar 12, 2016 at 6:31 AM, Jim Nasby wrote:
> On 3/10/16 8:36 PM, Robert Haas wrote:
>>
>> 1. We make it true only for heavyweight lock waits, and false for
>> other kinds of waits. That's pretty strange.
>> 2. We make it true for all kinds of waits that we now know how to
>> report. That
On Sun, Mar 13, 2016 at 12:40 AM, Tom Lane wrote:
> In short: we've already been over this territory, at length,
> and I am not excited by people trying to bikeshed it again
> after the fact, especially when no new arguments are being
> presented. Can we call the discussion closed, please?
Close
On Wed, Jan 20, 2016 at 5:29 PM, Andres Freund wrote:
> I think one thing we should work on, is being absolutely religious about
> requiring, say, 2 reviews for every nontrivial contribution. We
> currently seem to have a significantly increased submission rate, and at
> the same time the number
I would love to see autonomous transactions in core.
I just have one major concern, but thankfully it's easily addressed.
There should be a way to within the session and/or txn permanently
block autonomous transactions.
This is important if you as a caller function want to be sure none of
the wo
On Wed, Aug 31, 2016 at 6:41 AM, Jaime Casanova
wrote:
>
> On 30 August 2016 at 23:10, Joel Jacobson wrote:
> >
> > There should be a way to within the session and/or txn permanently
> > block autonomous transactions.
> >
>
> This will defeat one of the
On Thu, Sep 1, 2016 at 12:12 AM, Vik Fearing wrote:
> Part of what people want this for is to audit what people *try* to do.
> We can already audit what they've actually done.
>
> With your solution, we still wouldn't know when an unauthorized attempt
> to do something happened.
The unauthorized
On Wed, Aug 31, 2016 at 6:22 PM, Simon Riggs wrote:
> On 31 August 2016 at 14:09, Joel Jacobson wrote:
>> My idea on how to deal with this would be to mark the function to be
>> "AUTONOMOUS" similar to how a function is marked to be "PARALLEL
>> SAFE",
On Thu, Sep 1, 2016 at 8:38 PM, Andres Freund wrote:
>
> I'm not convinced this makes much sense. All FDWs, dblink etc. already
> allow you do stuff outside of a transaction.
You as a DBA can prevent FDWs from being used and dblink is an
extension that you don't have to install.
So if preventing
On Sun, Feb 19, 2017 at 5:58 PM, Robert Haas wrote:
>> When case preservation by default is on, then simply enforce
>> UNIQUE(LOWER(object_name)), to prevent ambiguity.
>
> That (1) breaks backward compatibility, because people might have
> objects with names identical except for case in existing
On Mon, Feb 20, 2017 at 2:40 AM, Jim Nasby wrote:
> Even if the project decided that "Users" and users is stupid and that we
> should deprecate it, I think the odds of also deciding to tell existing
> users to re-write their apps are zero.
But if the feature can't be turned on without also enforc
On Mon, Feb 20, 2017 at 1:45 AM, Tom Lane wrote:
> The versions of autocommit that have actually stood the test of time were
> implemented on the client side (in psql and JDBC, and I think ODBC as
> well), where the scope of affected code was lots smaller. I wonder
> whether there's any hope of p
Hi Hackers,
Currently, it's only possible to grant/revoke execute on functions to roles.
I think it would be useful in many situations, both for documentation purposes,
but also for increased security, to in a precise way control what
other function(s)
are allowed to execute a specific function.
On Wed, Feb 22, 2017 at 9:07 AM, Pavel Stehule wrote:
> Usage of X functions can be locked in schema.
I think that's also a good idea. Both are useful I think. They solve
two different use-cases.
If there are multiple callers of a private function within a schema,
it would be useful if you could
On Wed, Feb 22, 2017 at 2:18 PM, Tom Lane wrote:
> I think this is really *not* a good idea. The entire permissions model
> is built around granting permissions to roles, by other roles.
My bad. I shouldn't have proposed the idea on how to achieve/implement the idea.
I should instead just have
On Thu, Feb 23, 2017 at 8:04 AM, Robert Haas wrote:
>
> It doesn't sound like a good solution to me, because there can be SQL
> code inside stored procedures that clients never see.
In our code base, we use CamelCase in all PL/pgSQL functions, both for
columns and variables,
e.g. SELECT UserID IN
Hi hackers,
A colleague of mine wondered if there is a way to always run
everything you type into psql in a db txn and automatically rollback
it as soon as it finish.
I couldn't think of any way to do so, but thought it would be a nice
feature and probably quite easy to add to psql, so I thought I
+1
On Tue, Jun 20, 2017 at 8:54 PM, Alvaro Herrera
wrote:
> Unless you have a lot of users running psql manually, I don't see how
> this is actually very useful or actionable. What would the user do with
> the information? Hopefully your users already trust that you'd keep the
> downtime to the
On Mon, Jun 26, 2017 at 9:35 PM, David G. Johnston
wrote:
> We already have SET TRANSACTION READ ONLY.
But in my use-case I am OK with the query doing write operations,
since sometimes you need to test something in prod (that cannot be
tested easily locally) but you want to ROLLBACK the query as
On Fri, Jul 24, 2015 at 9:39 PM, Merlin Moncure wrote:
> On Thu, Jul 23, 2015 at 1:49 PM, Josh Berkus wrote:
> > Batch Jobs: large data-manipulation tasks which need to be broken up
> > into segments, with each segment committing separately. Example:
> > updating 1 million records in batches of
On Mon, Jul 27, 2015 at 11:49 PM, Josh Berkus wrote:
> Ah, you're missing how commits in ATX are expected to work. Let me
> illustrate:
>
> X (
>Data write A1
>call Y(
> Start ATX
> Data write B1
> Commit ATX
>)
>Data write A2
>Exception
> )
>
> In thi
On Tue, Jul 28, 2015 at 12:56 AM, Josh Berkus wrote:
> Ah, ok. The goal of the project is that the writer of X() *cannot*
> prevent Y() from writing its data (B1) and committing it.
>
> One of the primary use cases for ATX is audit triggers. If a function
> writer could override ATX and preven
On Wed, Jan 15, 2014 at 1:34 AM, Marko Tiikkaja wrote:
> Hi all!
>
> It's me again, trying to find a solution to the most common mistakes I make.
> This time it's accidental shadowing of variables, especially input
> variables. I've wasted several hours banging my head against the wall while
> sh
On Tue, Mar 4, 2014 at 12:55 AM, Tom Lane wrote:
> You're reasoning from a false premise: it's *not* necessarily an error.
When wouldn't it be an error? Can you give a real-life example of when
it would be a good idea to use the same name of an input parameter as
a declared variable?
Isn't this
On Tue, Mar 4, 2014 at 4:06 PM, Tom Lane wrote:
> Joel Jacobson writes:
>> On Tue, Mar 4, 2014 at 12:55 AM, Tom Lane wrote:
>>> You're reasoning from a false premise: it's *not* necessarily an error.
>
>> Isn't this almost exactly the same situation as
On Tue, Mar 4, 2014 at 8:04 PM, Andrew Dunstan wrote:
> Lots of code quite correctly relies on this,
> including some I have written.
I really cannot see when it would be a good coding practise to do so,
there must be something I don't understand, I would greatly appreciate
if you can give a real
On Tue, Sep 22, 2015 at 3:20 PM, Andres Freund wrote:
> What I've tested is the following:
> * continous burning of multis, both triggered via members and offsets
> * a standby keeping up when the primary is old
> * a standby keeping up when the primary is new
> * basebackups made while a new prim
The introduction of custom_variable_classes and #variable_conflict in
9.0 partly solves the problem with mixing IN/OUT variables with column
names.
In 8.4 and before, it defaulted to the IN/OUT variable, if it shared
the name of a column.
In 9.0 the behaviour was changed to raise an error if a vari
Entering the discussion because this is a huge pain for me in my daily
work as well.
This is not a reply to any specific post in this thread, but my first
message in the thread.
I see a great value in providing both a GUC and a new RAISE syntax.
The different benefits of the two are maybe obvious
On Fri, Apr 24, 2015 at 1:16 PM, Robert Haas wrote:
>> This would allow doing something crazy as:
>>
>> suppress_context_messages = warning,error
>> display_context_messages = notice
>
> This is a very flexible proposal, but it's a tremendous amount of
> machinery for what's really a very minor is
On Fri, Apr 24, 2015 at 6:07 PM, Pavel Stehule wrote:
>> Example:
>>
>> context_messages = -warning, -error, +notice
>
>
> I prefer your first proposal - and there is a precedent for plpgsql -
> plpgsql_extra_checks
>
> It is clean for anybody. +-identifiers looks like horrible httpd config. :)
I
+1
On Sat, Apr 25, 2015 at 10:23 PM, Pavel Stehule
wrote:
> Hi
>
> 2015-04-24 19:16 GMT+02:00 Joel Jacobson :
>
>> On Fri, Apr 24, 2015 at 6:07 PM, Pavel Stehule
>> wrote:
>> >> Example:
>> >>
>> >> context_messages = -warning, -erro
Pavel
>
> 2015-04-25 22:23 GMT+02:00 Pavel Stehule :
>
>> Hi
>>
>> 2015-04-24 19:16 GMT+02:00 Joel Jacobson :
>>
>>> On Fri, Apr 24, 2015 at 6:07 PM, Pavel Stehule
>>> wrote:
>>> >> Example:
>>> >>
>&g
On Mon, Apr 27, 2015 at 6:14 PM, Marko Tiikkaja wrote:
> That sounds weird. log_min_messages are the messages sent to the log;
> client_min_messages are sent to the client. context_min_messages are not
> sent to a "context", whatever that would mean.
Good point.
I think it can't be any clear
Hi,
For those of you who use PL/pgSQL every day, I'm quite certain you all feel
there are a number of things you would like to change in the language, but
realize it cannot be achieved without possibly breaking compatibility, at
least in theory. Even though you own code would survive the change, t
On Sat, Jul 26, 2014 at 8:39 PM, Tom Lane wrote:
> Basically my point is that this just seems like inventing another way to
> do what one can already do with RAISE, and it doesn't have much redeeming
> social value to justify the cognitive load of inventing another construct.
The main difference
On Mon, Sep 1, 2014 at 11:24 AM, Andres Freund wrote:
> -many.
>
> Look at the *disaster* the few minor changes in python3 were. It's now,
> years after, only starting to get used again.
>
> You're going to have to find a more gradual way of doing this.
I agree this is a valid concern, and is als
On Mon, Sep 1, 2014 at 12:32 PM, Hannu Krosing wrote:
> it would be
>
> ...
> [ WITH ( [LOCAL] attribute [, ...] ) ]
>
> where LOCAL attributes are _not_ inherited by nested functions
> but the LOCALs would shadow globals in the function definitions
> that have them.
>
> I know it is easier sa
On Mon, Sep 1, 2014 at 12:55 PM, Andres Freund wrote:
> The likelihood of us now knowing all the things that we want to break
> rigth now seems about zero. There *will* be further ones. If we go with
> the approach of creating new language versions for all of them we'll end
> up with a completely
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 signal -
> so we should not to do.
Do you
On Mon, Sep 1, 2014 at 2:53 PM, Pavel Stehule wrote:
> It bad signal to have two languages plpgsql and plpgsql2. Who will believe
> to us so we will continue development of plpgsql?
Depends on how you define "development".
Bugfixes of plpgsql? Yes, of course.
New features? No, but that's a non-is
On Mon, Sep 1, 2014 at 3:25 PM, Andres Freund wrote:
> On 2014-09-01 15:19:41 +0200, Joel Jacobson wrote:
>> On Mon, Sep 1, 2014 at 2:53 PM, Pavel Stehule
>> wrote:
>> > It bad signal to have two languages plpgsql and plpgsql2. Who will believe
>> > to us s
+1
I use underscore for *all* variables and input parameters in all
functions. Making that a requirement in plpgsql2 wouldn't break any of
my code.
On Mon, Sep 1, 2014 at 3:52 PM, Craig Ringer wrote:
> On 09/01/2014 05:04 PM, Joel Jacobson wrote:
>> From the top of my head, thes
On Mon, Sep 1, 2014 at 4:26 PM, Craig Ringer wrote:
> Well, the idiom:
>
> EXECUTE format("SELECT %I FROM %I WHERE $1", col, tbl) USING val;
>
> is not lovely. It works, but it's clumsy.
This is exactly why we need a new language.
All the clumsy stuff we cannot fix in plpgsql, can easily be fix
On Mon, Sep 1, 2014 at 4:41 PM, Andres Freund wrote:
>> I'm just saying it's much less probable you can add new features to
>> plpgsql than to plpgsql2, as you have to take into account the risk of
>> breaking compatibility.
>
> That's just a difference of one release. The release after the set of
On Mon, Sep 1, 2014 at 5:16 PM, Craig Ringer wrote:
> On 09/01/2014 10:41 PM, Joel Jacobson wrote:
>> This is exactly why we need a new language.
>> All the clumsy stuff we cannot fix in plpgsql, can easily be fixed in
>> plpgsql2, with the most beautiful syntax we can come u
On Mon, Sep 1, 2014 at 5:45 PM, Tom Lane wrote:
> What is actually being proposed, AFAICS, is a one-shot fix for a bunch
> of unfortunate choices. That might be worth doing, but let's not fool
> ourselves about whether it's one-shot or not.
I'm glad to hear you think it *might* be worth doing.
A
On Mon, Sep 1, 2014 at 8:38 PM, Tom Lane wrote:
> c) plpgsql and plpgsql2 are the same code base, with a small number
> of places that act differently depending on the language version.
+1 to the idea
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
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 Postgres? What could be one of
> the kil
On Tue, Sep 2, 2014 at 5:46 AM, Craig Ringer wrote:
> My point is that weeks can be spent just arguing about whether you
> should have a variable-delimiter ($variable) or not, how syntax should
> look, etc. Imagine how long it'd take to get a new language syntax
> agreed upon?
I would guess about
On Tue, Sep 2, 2014 at 8:26 AM, Heikki Linnakangas
wrote:
> On 09/02/2014 09:06 AM, Joel Jacobson wrote:
>> For me, the most important is to not break *most* of existing plpgsql
>> code, but it's OK to break *some*.
>> And when breaking it, it should be trivi
On Tue, Sep 2, 2014 at 11:04 AM, Pavel Stehule wrote:
> What we can do better?
>
> 1. we can implement a conditional RAISE
>
> DELETE FROM tab WHERE xx = somevar;
> GET DIAGNOSTICS rc = ROW_COUNT;
> RAISE EXCEPTION 'some' WHEN rc <> 0;
>
> It is relatively natural and we use similar construct in
On Tue, Sep 2, 2014 at 3:12 PM, Kevin Grittner wrote:
> Joel Jacobson wrote:
>
>> + Make UPDATE/INSERT/DELETE throw error if they didnt' modify
>> exactly 1 row, as that's the most common use-case, and provide
>> alternative syntax to modify multiple or zero r
On Tue, Sep 2, 2014 at 2:29 PM, Heikki Linnakangas
wrote:
> In the mailing list thread that you linked there, Tom suggested using
> "STRICT UPDATE ..." to mean that updating 0 or >1 rows is an error
> (http://www.postgresql.org/message-id/16397.1356106...@sss.pgh.pa.us). What
> happened to that pr
On Tue, Sep 2, 2014 at 2:30 PM, Pavel Stehule wrote:
> It is way how to do COBOL from plpgsql. I am against it. Start to develop
> new language what will support fast development, but it is wrong way for
> plpgsql - and It is out my interest
Are you saying COBOL by default update's one row and th
On Tue, Sep 2, 2014 at 3:41 PM, Heikki Linnakangas
wrote:
> On 09/02/2014 04:32 PM, Joel Jacobson wrote:
>> I think it's much better to make it the default behaviour in plpgsql2
>> than to add a new syntax to plpgsql,
>> because then we don't have to argue what
On Tue, Sep 2, 2014 at 3:58 PM, Marko Tiikkaja wrote:
> When I've played around with the idea of fixing PL/PgSQL in my head, what I
> had in mind is that UPDATE and DELETE not affecting exactly one row raises
> an exception, unless PERFORM is used. PERFORM would set a special variable
> (e.g. ROW
On Tue, Sep 2, 2014 at 5:08 PM, Kevin Grittner wrote:
> Marko Tiikkaja wrote:
>> No, but your code can have a bug.
>
> So the main use case is to allow buggy functions which are deployed
> to production without adequate testing to be detected? Bugs like
> not getting the primary key column(s) ri
On Tue, Sep 2, 2014 at 6:03 PM, Heikki Linnakangas
wrote:
> I think that would actually be a good way to enforce the rule that an UPDATE
> only updates a single row. Just put a "ASSERT ROW_COUNT=1;" after the
> update.
So instead of one line of code, I would need to write two lines of
code at alm
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
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
> *easily*, *transparently* beyond one node. Postgres doesn't. I'm not saying
> they do
On Tue, Sep 2, 2014 at 6:31 PM, Heikki Linnakangas
wrote:
> I don't think most applications are like that. See Kevin's comments about
> doing things in a set-oriented way instead of row-by-row. I know I've
> changed several procedures from the row-oriented style, looping over rows
> with a FOR loo
On Tue, Sep 2, 2014 at 6:45 PM, Bruce Momjian wrote:
> SINGLETON UPDATE ...?
Does it come with built-in spell check? :-) It's a bit long to write.
I like STRICT, that maps good to what we already have with SELECT ...
INTO STRICT.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql
On Tue, Sep 2, 2014 at 7:01 PM, Bruce Momjian wrote:
> On Tue, Sep 2, 2014 at 06:57:42PM +0200, Joel Jacobson wrote:
>> On Tue, Sep 2, 2014 at 6:45 PM, Bruce Momjian wrote:
>> > SINGLETON UPDATE ...?
>>
>> Does it come with built-in spell check? :-) It's a
On Tue, Sep 2, 2014 at 10:16 PM, Andres Freund wrote:
> On 2014-09-02 19:06:02 +0200, Joel Jacobson wrote:
>> But what do you think about,
>> STRICT UPDATE ...?
>
> I quite dislike it. An UPDATE isn't less 'strict' (whatever that means)
> if updates more
On Tue, Sep 2, 2014 at 10:27 PM, Merlin Moncure wrote:
> What is the reasoning for breaking compatibiilty? Why not improve the
> language that's there?
Because many suggested improvement are not possible without
breaking compatibility, at least in theory. See previous posts in the thread.
> whe
On Wed, Sep 3, 2014 at 12:19 AM, Josh Berkus wrote:
> On 09/01/2014 02:04 AM, Joel Jacobson wrote:
>> Please share your wish list of things you would want in plpgsql2 which
>> are not possible to implement in plpgsql because they could possibly
>> break compatibility
On Wed, Sep 3, 2014 at 2:46 AM, Christopher Browne wrote:
> The notion of hacking features onto plpgsql2 that mostly seem like SQL
> enhancements is a waste of time.
New versions of languages who change too much in a new version are
doomed to fail. There are many such examples in history.
Complet
On Wed, Sep 3, 2014 at 7:17 AM, Pavel Stehule wrote:
> yes, but there is minimal agreement of direction of movement. I am not alone
> who are thinking so your proposal is not good for general usage.
Minimal agreement? That's not true. The other group of users have been
discussing
a completely new
On Wed, Sep 3, 2014 at 7:54 AM, Pavel Stehule wrote:
> I am not against to improve a PL/pgSQL. And I repeat, what can be done and
> can be done early:
>
> a) ASSERT clause -- with some other modification to allow better static
> analyze of DML statements, and enforces checks in runtime.
>
> b) #op
On Wed, Sep 3, 2014 at 10:07 AM, Pavel Stehule wrote:
> When you use name plpgsql2 you say, so plpgsql2 is successor plpgsql. It is
> very hard to accept it. So any other name is not problem for me - like
> plpgsql-safe-subset or something else
plpgsql2 *is* the successor of plpgsql, that's why
On Wed, Aug 6, 2014 at 2:46 PM, Marko Tiikkaja wrote:
> Hi hackers,
>
> Attached is a patch to add support for PGP signatures in encrypted messages
> into pgcrypto.
I noticed Heikki wanted to check if there is any interested for the
patches in the current commitfest.
Yes, our company Trustly are
On Wed, Sep 3, 2014 at 3:17 PM, Joshua D. Drake wrote:
> Well, I don't think PostgreSQL needs its own PL. I mean we already have
> several (what other database has pl/javascript or pl/python?)
PostgreSQL already *have* it's own PL, it's called PL/pgSQL.
> Besides, the idea of this community tryi
On Wed, Sep 3, 2014 at 11:19 PM, Hannu Krosing wrote:
> SELECT[1] - select exactly one row, anything else raises error
> SELECT[0:1] - select zero or one rows, anything else raises error
> SELECT[1:] - select one or more rows
>
> plain SELECT is equivalent to SELECT[0:]
>
> same syntax could b
On Thu, Sep 4, 2014 at 9:39 AM, Pavel Stehule wrote:
> we have totally different opinion what is good
Can you elaborate on that?
Your "ASSERT CHECK ROWCOUNT = 1;" is lengthly, which is why I don't like it.
Imagine if having to type
my $var === 'foo';
instead of
my $var =
a good thing to
make it simple also for UPDATE/DELETE/INSERT.
On Thu, Sep 4, 2014 at 10:42 AM, Pavel Stehule wrote:
>
>
>
> 2014-09-04 10:06 GMT+02:00 Joel Jacobson :
>
>> On Thu, Sep 4, 2014 at 9:39 AM, Pavel Stehule
>> wrote:
>> > we have totally diffe
On Thu, Sep 4, 2014 at 11:07 AM, Pavel Stehule wrote:
> it is different semantic - returns composite or set of composites --- it is
> not row or rows
The point was, RETURNS returns 1 while RETURNS SETOF returns 0 .. n.
> Actually BL is usually processed oriented, so PL functions coverages chang
On 4 sep 2014, at 11:42, Pavel Stehule wrote:
2014-09-04 11:22 GMT+02:00 Joel Jacobson :
>
> The point was, RETURNS returns 1 while RETURNS SETOF returns 0 .. n.
>
no RETURNS return "VALUE" (it is not a row) .. and in combination with
SELECT - value will be a row. RETURNS SET
> On 4 sep 2014, at 15:09, Shaun Thomas wrote:
>
>> On 09/01/2014 04:04 AM, Joel Jacobson wrote:
>>
>> + Make UPDATE/INSERT/DELETE throw error if they didnt' modify exactly 1
>> row, as that's the most common use-case, and provide alternative syntax
>
On 4 sep 2014, at 15:32, Pavel Stehule wrote:
2014-09-04 15:24 GMT+02:00 Jan Wieck :
> On 09/04/2014 01:14 AM, Pavel Stehule wrote:
>
>> 2014-09-03 23:19 GMT+02:00 Hannu Krosing > A more SQL-ish way of doing the same could probably be called COMMAND
>> CONSTRAINTS
>> and look some
> On 4 sep 2014, at 16:45, Hannu Krosing wrote:
>
> When looking from the other end of the problem, we are
> using SELECT/INSERT/UPDATE/DELETE *SET statements* in pl/pgsql
> when we really want scalars.
>
> My understanding is that one main drivers of starting this thread
> was wanting also guaran
> On 4 sep 2014, at 17:18, Pavel Stehule wrote:
>
> You just need a ISAM API for Postgres, That is all.
Now you are being ironic, and I would prefer to keep the discussion on
a serious level. You know that's not applicable in my case, you know
what I do for work and what kind of system we already
Marko, et al,
This is a review of the pgcrypto PGP signatures patch:
http://www.postgresql.org/message-id/53edbcf0.9070...@joh.to
There hasn't been any discussion, at least that I've been able to find.
Contents & Purpose
==
This patch add functions to create, verify and extract i
On Thu, Sep 4, 2014 at 5:51 PM, Robert Haas wrote:
>> When you suggest ISAM, that's like saying "demolish your house and
>> build a new one" when all I want is to make small but important
>> changes to what I already do as a professional on a daily basis.
>
> Go right ahead: this is an open source
Marko, et al,
This is a review of the pgcrypto PGP Armor Headers patch:
http://www.postgresql.org/message-id/53edcae8.20...@joh.to
Contents & Purpose
==
This patch add functions to create and extract OpenPGP Armor Headers.
from OpenPGP messages.
Included in the patch are updated
> On 3 sep 2014, at 16:20, Robert Haas wrote:
>
>> On Mon, Sep 1, 2014 at 5:08 AM, Joel Jacobson wrote:
>>> On Sat, Jul 26, 2014 at 8:39 PM, Tom Lane wrote:
>>> Basically my point is that this just seems like inventing another way to
>>> do what one ca
On Sat, Sep 6, 2014 at 6:59 AM, Pavel Stehule wrote:
> People can prepare a simple functions like you did:
>
> ...
>
> CREATE OR REPLACE FUNCTION user_list ()
> RETURNS SETOF id AS $$
> BEGIN
> RETURN QUERY SELECT id FROM user WHERE .. some = $1
> END;
> $$ LANGUAGE plpgsql;
>
> CREATE OR REPLAC
On Sat, Sep 6, 2014 at 7:51 AM, Pavel Stehule wrote:
> Hi
>
> There was a long discussion about future of PLpgSQL.
>
> I accept so Joel, Marko has good ideas based on probably strong experience
> from their domain. I can't accept their implementation and proposals as
> default for PLpgSQL now and
> On 6 sep 2014, at 16:32, Marko Tiikkaja wrote:
>
> How do you run queries which affect more than one row in this mode? Because
> that's crucial as well. We want something we can run 100% of our code on,
> but with a slightly more convenient syntax than PL/PgSQL provides right when
> coding d
On Mon, Nov 30, 2015 at 8:43 PM, Tom Lane wrote:
> * Finish multixact truncation rework
>
> We're not seriously going to push something this large into 9.5 at this
> point, are we?
I don't know all the details here, so my apologies if any of this is
incorrect/stupid/misinformed.
Given all the qu
On Wed, Dec 2, 2015 at 12:19 PM, Andres Freund wrote:
> The significant changes are in 9.5.
Will multixact truncations be WAL logged in 9.5?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hack
1 - 100 of 263 matches
Mail list logo
