On 9/18/14 1:35 PM, Martijn van Oosterhout wrote:
On Wed, Sep 17, 2014 at 10:17:22PM +0200, Pavel Stehule wrote:
Because you still have to do
SELECT pg_temp.my_temp_function(blah);
to execute it.
this problem should be solvable. I can to use a temporary tables without
using pg_temp sch
On 9/17/14, 9:00 PM, Peter Eisentraut wrote:
On 9/14/14 2:49 PM, Jan Wieck wrote:
I don't think it is even a good idea to implement assertions that can
query arbitrary data.
In a normal programming language, an assertion is usually a static fault
in your program. If the assertion ever fails,
On 9/10/14 1:38 PM, Heikki Linnakangas wrote:
On 09/10/2014 02:26 PM, Marko Tiikkaja wrote:
So I wonder if I shouldn't try and instead keep the
code closer to what it is in HEAD right now; I could call
enlargeStringInfo() first, then hand out a pointer to b64_encode (or
b64_decode()
On 9/9/14 11:01 AM, I wrote:
On 9/9/14 10:54 AM, Heikki Linnakangas wrote:
So I think this (and the corresponding dearmor code too) should be
refactored to use a StringInfo that gets enlarged as needed, instead of
hoping to guess the size correctly beforehand. To ease review, might
make sense to
On 9/10/14 12:05 PM, Etsuro Fujita wrote:
(2014/09/10 18:33), Marko Tiikkaja wrote:
You can already change *this patch* to do ModifyTable <- Limit <-
LockRows. If we think that's what we want, we should rewrite this patch
right now.
I think it might be relatively easy to do that
On 9/10/14 11:25 AM, Etsuro Fujita wrote:
The reason is because I think that after implementing #2, we should
re-implement this feature by extending the planner to produce a plan
tree such as ModifyTable+Limit+Append, maybe with LockRows below the
Limit node. Such an approach would prevent dupli
On 2014-09-10 04:25, Etsuro Fujita wrote:
(2014/09/09 18:57), Heikki Linnakangas wrote:
What's not clear to me is whether it make sense to do 1) without 2) ? Is
UPDATE .. LIMIT without support for an ORDER BY useful enough? And if we
apply this patch now, how much of it needs to be rewritten aft
On 9/9/14 12:37 PM, I wrote:
And no, these are not routine things so keep your "use
partitions" suggestions to yourselves.
My apologies. This was not directed at you personally, Heikki, and in
any case it was unnecessarily hostile.
.marko
--
Sent via pgsql-hackers mailing list (pgsql-hac
On 9/9/14 11:57 AM, Heikki Linnakangas wrote:
What's not clear to me is whether it make sense to do 1) without 2) ? Is
UPDATE .. LIMIT without support for an ORDER BY useful enough?
I'd say so; I could use it right now. I have to remove millions of
lines from a table, but I don't want the liv
On 9/9/14 10:54 AM, Heikki Linnakangas wrote:
So I think this (and the corresponding dearmor code too) should be
refactored to use a StringInfo that gets enlarged as needed, instead of
hoping to guess the size correctly beforehand. To ease review, might
make sense to do that as a separate patch o
On 2014-09-09 07:54, Craig Ringer wrote:
On 09/05/2014 05:21 PM, Pavel Stehule wrote:
*shrug* Doing it in SQL would probably break more stuff. I'm trying to
contain the damage. And arguably, this is mostly only useful in PL/PgSQL.
I've wanted assertions in SQL enough that I often write tri
On 2014-09-08 7:30 PM, Jeff Janes wrote:
On Fri, Sep 5, 2014 at 4:38 AM, Marko Tiikkaja wrote:
I've also changed the behaviour when passing a message with a signature to
the decrypt functions which don't verify signatures. They now report
"ERROR: Wrong key or corrupt d
On 2014-09-07 19:28, Jeff Janes wrote:
On Wed, Sep 3, 2014 at 2:13 PM, Marko Tiikkaja wrote:
To sign without encrypting?
To verify signatures of things that are not encrypted. I'm not really
interested in storing private keys in PostgreSQL, just things that can be
done with public
On 2014-09-06 9:47 PM, Pavel Stehule wrote:
-1 .. to proposal .. It is in contradiction with current feature.
Which feature would that be?
Next it
is nonsense. INTO clause should to contains only plpgsql variables - in 9.x
Postgres there is not possible issue.
postgres=# create table x(a int,
On 2014-09-06 7:56 PM, Pavel Stehule wrote:
2014-09-06 19:54 GMT+02:00 Marko Tiikkaja :
Then that doesn't really solve our problem. Switching between two
languages on a per-function basis, when both look exactly the same but have
very different semantics would be a nightmare.
It is ma
On 2014-09-06 7:49 PM, Pavel Stehule wrote:
this doesn't to supply assertions, it is just shorter form
The original proposal very clearly seems to be "why don't we do this
*instead* of assertions?" And in that case all of my points apply, and
I'm very much against this syntax. If this is su
On 2014-09-06 7:50 PM, Pavel Stehule wrote:
2014-09-06 16:31 GMT+02:00 Marko Tiikkaja :
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/
On 2014-09-06 7:34 PM, Oskari Saarenmaa wrote:
Anyway, I think the discussed feature to make select, update and delete
throw an error if they returned or modified <> 1 row would be more
useful as an extension of the basic sql statements instead of a plpgsql
(2) only feature to make it possible to
On 2014-09-06 7:27 AM, Pavel Stehule wrote:
2014-09-05 14:35 GMT+02:00 Jan Wieck :
Adding a WHEN clause to RAISE would have the benefit of not needing any
new keywords at all.
RAISE EXCEPTION 'format' [, expr ...] WHEN row_count <> 1;
It was one my older proposal.
Can we find a agreement th
On 2014-09-06 6:31 PM, Jan Wieck wrote:
On 09/06/2014 12:17 PM, Marko Tiikkaja wrote:
OK, fine. But that's not what I suggested on the wiki page, and is also
not what I'm arguing for here right now. What the message you referred
to was about was the condescending attitude where we
On 2014-09-06 6:12 PM, Jan Wieck wrote:
On 09/06/2014 04:21 AM, Marko Tiikkaja wrote:
We wrap these things into (sometimes) simple-looking function so that
none of the application developers ever run any SQL. We define an
interface between the application and the database, and that interface
On 2014-09-06 6:06 PM, Jan Wieck wrote:
You can dismiss what we're doing by saying that it doesn't follow the
best practices or we just want an interface for a key-value store or
whatever. And yes, to some extent, a simple interface for a key-value
store would come in handy. But we still have t
On 2014-09-05 1:38 PM, I wrote:
3) I've changed the code to use ntohl() and pg_time_t as per Thomas'
comments.
sig->creation_time = ntohl(*((uint32_t *) creation_time));
This is probably a horrible idea due to strict aliasing rules and
alignment, though. I think I'll just hide the bit
On 2014-09-06 4:41 PM, Joel Jacobson wrote:
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 th
On 2014-09-06 7:51 AM, Pavel Stehule wrote:
In this mode .. all DML statements should to return EXACTLY ONE row with
exception CURSORs and FOR LOOP cycle where more rows is expected. But in
this case we can raise a exception NODATA if there is no row.
In this mode late IO casting will be disable
(Forgot to answer to this part)
On 2014-09-06 06:59, Pavel Stehule wrote:
Your strategy is defensive. 100%. But then I don't understand to your
resistant to verbosity. It is one basic stone of Ada design
I've never programmed in Ada, but I don't necessarily see why "more
verbose" would uncon
On 2014-09-06 06:59, Pavel Stehule wrote:
People can prepare a simple functions like you did:
...
And then use it in mass operations:
BEGIN
FOR company IN SELECT * FROM company_list()
LOOP
FOR id IN SELECT * FROM user_list(company)
LOOP
update_user(id);
END LOOP;
On 2014-09-02 8:52 PM, Kevin Grittner wrote:
Marko Tiikkaja wrote:
Sounds like in this case you'd only use set-oriented programming
at the end of the transaction, no?
I guess -- more properly I would say "in the final database
transaction for that financial transaction."
On 2014-09-04 2:28 PM, I wrote:
On 9/4/14 2:04 PM, Pavel Stehule wrote:
for example best practices for PL/SQL by Steven Feuerstein
I'll spend some time with that book to have a better idea on where
you're coming from.
I've read through this book twice now. Some observations on things we
do
Hi,
First of all, sorry about breaking the thread; I don't subscribe to
-general so I can't copy the original email. This is in response to the
problem here:
http://www.postgresql.org/message-id/CACfv+p+8dToaR7h06_M_YMjpV5Na-CQq7kN=kgjq_k84h7u...@mail.gmail.com
Attached is a very ugly proof
On 2014-09-05 11:33 PM, David G Johnston wrote:
To protect users on every query they write there would need to be some kind
of "always explain first and only execute if no warnings are thrown"
mode...and ideally some way to then override that on a per-query basis if
you know you are correct and d
On 2014-09-05 11:19 PM, David G Johnston wrote:
Marko Tiikkaja-4 wrote
I think this is only problematic for column aliases. I wouldn't want to
put these two to be put into the same category, as I always omit the AS
keyword for tables aliases (and will continue to do so), but never omit
i
On 2014-09-05 22:56, Oskari Saarenmaa wrote:
What'd be a good name for the GUC controlling this,
missing_column_as_warning?
I don't know about others, but I've previously had the idea of having
more warnings like this (my go-to example is DELETE FROM foo WHERE bar
IN (SELECT bar FROM barless
On 2014-09-05 22:38, Oskari Saarenmaa wrote:
I wrote the attached patch to optionally emit warnings when column or table
aliases are used without the AS keyword after errors caused by typos in
statements turning unintended things into aliases came up twice this week.
First in a discussion with a
On 9/5/14 11:08 AM, Craig Ringer wrote:
On 09/05/2014 05:04 PM, Marko Tiikkaja wrote:
I really don't like the idea of relaxing casts. And I really object to
the notion of casting from test to date being "obviously right".
Gah. It's obviously right to *reject* implicit c
On 9/5/14 11:08 AM, Pavel Stehule wrote:
2014-09-05 10:57 GMT+02:00 Marko Tiikkaja :
Oops. I meant to type ASSERT there, instead of RAISE. Does that make
more sense?
for me a basic limit is boolean_expr
I don't understand what you mean by this.
It is about semantic and conformi
On 9/5/14 9:04 AM, Craig Ringer wrote:
It's easy to object to this on type-purist grounds, but from a pragmatic
real-users point of view what we currently do is outright painful, and
unless we can go and fix every language binding, every query generator,
every ORM, etc to handle things just how P
On 9/5/14 10:40 AM, Pavel Stehule wrote:
2014-09-05 10:33 GMT+02:00 Marko Tiikkaja :
I don't see why. The PL/PgSQL SQL parser goes to great lengths to
identify unmatched parenthesis. But the parens probably aren't necessary
in the first place; you could just omit them and keep par
On 9/5/14 10:09 AM, Pavel Stehule wrote:
I think this could still be parsed correctly, though I'm not 100% sure on
that:
ASSERT WARNING (EXISTS(SELECT ..)), 'data are there';
PLpgSQL uses a ';' or some plpgsql keyword as SQL statement delimiter. It
reason why RETURN QUERY ... ';' So in this c
On 2014-09-05 08:16, Pavel Stehule wrote:
Assert is usually implemented as custom functions and used via PERFORM
statement now
-- usual current solution
PERFORM Assert(some expression)
I would to implement Assert as plpgsql internal statement due bigger
possibilities to design syntax and intern
On 9/4/14 5:54 PM, Craig Ringer wrote:
On 09/04/2014 02:48 AM, Robert Haas wrote:
To take another example, I've been complaining about the fact
that PostgreSQL 8.3+ requires far more typecasts in stored procedures
than any other database I'm aware of for years, probably since before
I joined Ent
On 9/4/14 4:09 PM, Shaun Thomas wrote:
On 09/03/2014 04:19 PM, Hannu Krosing wrote:
1. Conditions for number of rows returned by SELECT or touched by
UPDATE or DELETE
Now that I think upon this... don't we already have it?
SELECT ... LIMIT 1
No, that just hides any bugs. We want the oppos
On 9/4/14 2:04 PM, Pavel Stehule wrote:
for example best practices for PL/SQL by Steven Feuerstein
I'll spend some time with that book to have a better idea on where
you're coming from.
Also, *please* don't try and extrapolate what I do based on the code
examples on the wiki page; they're a
On 9/4/14 1:47 PM, Pavel Stehule wrote:
2014-09-04 13:37 GMT+02:00 Marko Tiikkaja :
I've started a wiki page with the list of the things I could think of at
this very moment. I probably got the most annoying ones in there, but I
also might have forgotten about some things. I invite discu
Everyone,
I've started a wiki page with the list of the things I could think of at
this very moment. I probably got the most annoying ones in there, but I
also might have forgotten about some things. I invite discussion of
every suggestion on -HACKERS.
https://wiki.postgresql.org/wiki/Impr
On 9/4/14 10:42 AM, Pavel Stehule wrote:
2014-09-04 10:06 GMT+02:00 Joel Jacobson :
*) but there are probably equally who prefer to handle business logics
outside the database
It is maybe main difference between me and you. Usually I don't write CRUD
applications, and I am not sure if plpgsql
On 9/4/14 2:10 AM, Hannu Krosing wrote:
On 09/04/2014 12:17 AM, Marko Tiikkaja wrote:
I'm not sure how much I like that syntax in cases like:
WITH t AS (
-- multi-line query here
)
SELECT[0:] foo, bar
INTO _bat, _man
FROM foo
JOIN ..
JOIN ..
WHERE ..
-- etc
On 2014-09-03 23:19, Hannu Krosing wrote:
1. Conditions for number of rows returned by SELECT or touched by UPDATE
or DELETE
-
Enforcing number of rows returned/affected could be done using th
On 2014-09-03 10:33 PM, Jeff Janes wrote:
On Wed, Sep 3, 2014 at 12:43 PM, Marko Tiikkaja wrote:
Right. This patch only adds support for signing data when encrypting it
at the same time. There's no support for detached signatures, nor is there
support for anything other than signatur
On 2014-09-03 9:36 PM, Jeff Janes wrote:
I wanted to start simple so I have a file which is signed, but not
encrypted. I can't figure out what to do with it. All of the functions
seem to require that it also be encrypted. I tried providing an empty
password for pgp_sym_signatures but it didn'
On 9/3/14 5:05 PM, Bruce Momjian wrote:
On Wed, Sep 3, 2014 at 07:54:09AM +0200, 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,
On 9/3/14 4:46 PM, Robert Haas wrote:
Making it
suck more because you don't think it's as important as your feature
is, in my opinion, not cool.
I really can't see how that would make inheritance suck *more*. You
can't do UPDATE .. ORDER BY now, and you wouldn't be able to do it after
the pa
On 2014-09-02 22:24, Alvaro Herrera wrote:
Marko Tiikkaja wrote:
Do we have some kind of an agreement on what this patch should look
like? Is someone going to prepare an updated patch? Vik?
I think the only issue left for this to be committable is reindexdb
--all previously mentioned.
I
On 2014-08-29 01:00, Alvaro Herrera wrote:
Vik Fearing wrote:
Here are two patches for this.
The first one, reindex_user_tables.v1.patch, implements the variant that
only hits user tables, as suggested by you.
The second one, reindex_no_dbname.v1.patch, allows the three
database-wide variants
On 2014-09-02 19:33, Kevin Grittner wrote:
Marko Tiikkaja wrote:
Well, just off the top of my head a normal function invocation could be:
one worker working on a single "order" started by a single end user to
transfer money from one account to another. And we have *a lot* of code
Hi,
On 2014-09-02 15:04, Heikki Linnakangas wrote:
I think this patch has been thoroughly reviewed now. Committed, thanks!
Thank you, Heikki. And also big thanks to Fabien for the review!
.marko
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On 9/2/14 6:31 PM, Heikki Linnakangas wrote:
On 09/02/2014 07:12 PM, Joel Jacobson wrote:
For me, updating a row, is like setting a variable in a normal language.
No normal language would require two rows to set a variable.
It would be like having to do:
my $var = 10;
die unless $var =
On 9/2/14 6:03 PM, Heikki Linnakangas wrote:
Marko posted a patch to add assertions to PL/pgSQL last year, see
http://www.postgresql.org/message-id/5234af3f.4000...@joh.to. It was a
long thread, but in the end I think everyone was more or less OK with
the syntax "ASSERT ;". I also think that synt
On 9/2/14 5:08 PM, Kevin Grittner wrote:
Marko Tiikkaja wrote:
On 9/2/14 4:26 PM, Kevin Grittner wrote:
Joel Jacobson wrote:
The common use-case I have in mind is when you have a function
which takes some kind of ID as an input param, which maps to a
primary key in some table, which you
On 9/2/14 4:26 PM, Kevin Grittner wrote:
Joel Jacobson wrote:
The common use-case I have in mind is when you have a function
which takes some kind of ID as an input param, which maps to a
primary key in some table, which you want to update.
In that case FOUND works just fine. A primary key v
On 9/2/14 4:15 PM, Joel Jacobson wrote:
I don't like rebranding the PERFORM command, as that would require all
existing code with PERFORM commands to be changed.
I'm not saying the suggested syntax is perfect, but PERFORM should be
euthanized anyway. Or at least the need for it; perhaps there
On 9/2/14 3:52 PM, Joel Jacobson wrote:
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 to
On 9/2/14 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 proposal?
http://www
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 magnitude more users than pg),
that would benefit us all
On 9/2/14 11:04 AM, Pavel Stehule wrote:
It is relatively natural and we use similar construct in CONTINUE statement.
2. What can be next? We can implement some idiom (shortcut) for GET
DIAGNOSTICS
DELETE FROM tab WHERE xx = somevar;
RAISE EXCEPTION 'some' WHEN AFFECTED_ROW_COUNT <> 1;
Yes, a
On 2014-08-12 13:23, I wrote:
The compile-time raise parameter checking is a good move.
3 minor points:
- I would suggest to avoid "continue" within a loop so that the code is
simpler to understand, at least for me.
I personally find the code easier to read with the continue.
I've changed t
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 with a new syntax use
an already existing one? One that ma
On 9/1/14 2:53 PM, Pavel Stehule wrote:
2014-09-01 14:27 GMT+02:00 Joel Jacobson :
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
On 8/29/14 4:33 PM, Tom Lane wrote:
So either it has to be inside
ModifyTable or the ModifyTable has to somehow pass something to a Limit
node on top of it
... or we add a LockRows node below the Limit node. Yeah, that would make
UPDATE/LIMIT a tad slower, but I think that might be preferable
On 9/1/14 12:12 PM, Andres Freund wrote:
On 2014-09-01 12:00:48 +0200, Marko Tiikkaja wrote:
On 9/1/14 11:53 AM, Hannu Krosing wrote:
You're going to have to find a more gradual way of doing this.
Probably a better way (and there has been some talk of it) is
having some kind of P
On 9/1/14 11:53 AM, Hannu Krosing wrote:
On 09/01/2014 11:24 AM, Andres Freund wrote:
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.
Probably a better way (and
On 8/29/14 1:53 PM, I wrote:
This is just my personal opinion, but what I think should happen is:
1) We put the LIMIT inside ModifyTable like this patch does. This
doesn't prevent us from doing ORDER BY in the future, but helps numerous
people who today have to
Oops, looks like I didn't f
On 8/29/14 12:20 PM, Etsuro Fujita wrote:
The patch places limit-counting inside ModifyTable, and works well for
inheritance trees, but I'm not sure that that is the right way to go. I
think that this feature should be implemented in the way that we can
naturally extend it to the ORDER-BY-LIMIT
On 8/22/14, 2:57 AM, Thomas Munro wrote:
I took a quick look at your patch at
http://www.postgresql.org/message-id/53edbcf0.9070...@joh.to (sorry I
didn't reply directly as I didn't have the message). It applies
cleanly, builds, and the tests pass. I will hopefully have more to
say after I've p
On 8/21/14, 1:19 PM, Heikki Linnakangas wrote:
On 08/07/2014 01:11 AM, Marko Tiikkaja wrote:
On 7/21/14, 10:56 PM, I wrote:
Here's a patch which allows you to notice those annoying bugs with INTO
slightly more quickly. Adding to the next commit phest.
New version, fixed bugs wit
On 7/16/14 4:33 PM, Tom Lane wrote:
Rajeev rastogi writes:
I found and fixed a bug that causes recovery (crash recovery , PITR) to throw
unwanted LOG message if the tablespace symlink is not found during the
processing of DROP TABLESPACE redo.
LOG: could not
Hi,
On 8/8/14 3:18 PM, I wrote:
Currently there's no way to generate or extract armor headers from the
PGP armored format in pgcrypto. I've written a patch to add the
support.
Latest version of the patch here, having fixed some small coding issues.
.marko
*** a/contrib/pgcrypto/Makefile
---
Hi Fabien,
On 8/12/14 1:09 PM, Fabien COELHO wrote:
Here's a patch for making PL/PgSQL throw an error during compilation (instead
of runtime) if the number of parameters passed to RAISE don't match the
number of placeholders in error message. I'm sure people can see the pros of
doing it this wa
Hi,
Currently there's no way to generate or extract armor headers from the
PGP armored format in pgcrypto. I've written a patch to add the
support. For example:
local:marko=#* select armor('zooka', array['Version', 'Comment'],
array['Created by pgcrypto', 'PostgreSQL, the database']);
On 7/21/14, 10:56 PM, I wrote:
Here's a patch which allows you to notice those annoying bugs with INTO
slightly more quickly. Adding to the next commit phest.
New version, fixed bugs with set operations and VALUES lists.
.marko
*** a/doc/src/sgml/plpgsql.sgml
--- b/doc/src/sgml/plpgsql.sgml
Hi hackers,
Attached is a patch to add support for PGP signatures in encrypted
messages into pgcrypto.
Currently, the list of limitations is the following:
- It only knows how to generate one signature per message. I don't
see that as a problem.
- If a message has been signed with m
On 1/14/14, 6:15 PM, Tom Lane wrote:
We don't actually implement this in PG yet, except for trivial cases, but
it will certainly happen eventually. I think your sketch above deviates
unnecessarily from what the standard says for UPDATE. In particular
I think it'd be better to write things like
On 7/28/14 11:27 AM, Simon Riggs wrote:
On 26 July 2014 18:14, Marko Tiikkaja wrote:
Today I'd like to present a way to get rid of code like this:
You haven't explained this very well... there is nothing that explains
WHY you want this.
In the absence of a good explanation an
On 7/26/14, 8:39 PM, Tom Lane wrote:
Marko Tiikkaja writes:
I'm not sure which case you're envisioning. A label is required, and
the label must be that of a BEGIN block with an EXCEPTION block if USING
ROLLBACK is specified. If that doesn't answer your question, could
Me again,
Here's a patch for making PL/PgSQL throw an error during compilation
(instead of runtime) if the number of parameters passed to RAISE don't
match the number of placeholders in error message. I'm sure people can
see the pros of doing it this way.
.marko
*** a/src/pl/plpgsql/src/pl
On 7/26/14, 8:22 PM, Tom Lane wrote:
In particular, what happens if someone attaches USING ROLLBACK
to an EXIT that does not lead from inside to outside a BEGIN/EXCEPTION
block?
I'm not sure which case you're envisioning. A label is required, and
the label must be that of a BEGIN block with a
Hello,
Today I'd like to present a way to get rid of code like this:
$$
BEGIN
BEGIN
INSERT INTO foo VALUES (1);
-- run some tests/checks/whatever
RAISE EXCEPTION 'OK';
EXCEPTION WHEN raise_exception THEN
IF SQLERRM <> 'OK' THEN
RAISE;
END IF;
END;
RETURN '
On 7/22/14, 7:06 AM, Pavel Stehule wrote:
I looked on this patch and I am thinking so it is not a good idea. It
introduce early dependency between functions and pg_class based objects.
What dependency? The patch only looks at the raw parser output, so it
won't e.g. know whether SELECT * INT
Hi again,
Here's a patch which allows you to notice those annoying bugs with INTO
slightly more quickly. Adding to the next commit phest.
.marko
*** a/doc/src/sgml/plpgsql.sgml
--- b/doc/src/sgml/plpgsql.sgml
***
*** 4730,4736 a_output := a_output || $$ if v_$$ || referrer_k
On 2014-06-24 11:08, Heikki Linnakangas wrote:
IMHO this needs to work with inheritance if we are to accept it. It
would be a rather strange limitation for no apparent reason, other than
that we didn't bother to implement it. It doesn't seem very difficult in
theory to add the table OID to the pl
On 2014-07-20 14:06, Andres Freund wrote:
On 2014-07-20 13:54:01 +0200, Andres Freund wrote:
On 2014-04-01 16:45:29 +0200, Fabien COELHO wrote:
I noticed that my pg_stat_statements is cluttered with hundreds of entries
like "DEALLOCATE dbdpg_p123456_7", occuring each only once.
Why isn't the
On 7/10/14 5:44 AM, Amit Kapila wrote:
Basically, I wanted to say that apart from modified columns, we just
need to pass table OID. If I am reading correctly, the same is
mentioned by Heikki as well.
Yes, Heikki was talking about that approach. I was more interested in
the significantly more
On 5/11/14 6:47 PM, Tom Lane wrote:
The $64 question is whether we'd accept an implementation that fails
if the target table has children (ie, is partitioned). That seems
to me to not be up to the project's usual quality expectations, but
maybe if there's enough demand for a partial solution we
Hi Amit,
On 5/14/14 6:41 AM, Amit Kapila wrote:
IIUC, the way new design will work is that for new tuple we will now
get tableoid+TID, modified column values as an input (for inheritance
tables we will get this for all child tables as well) for ModifyTable
and get old tuple (which in current cas
On 2014-06-19 1:46 AM, Josh Berkus wrote:
Robert's right, not killing the "BEGIN;" only transactions is liable to
result in user confusion unless we label those sessions differently in
pg_stat_activity.
Wouldn't they be labeled differently already? i.e. the last query would
be "BEGIN". Unles
quot;;
I've switched to using SELECT 1 in EXISTS for this reason, but perhaps
other people haven't yet done that..
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
uld be parsed unambiguously, though it's perhaps a bit
ugly.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
asking me about this feature for pg_extractor
No, the idea was rejected.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ero.
I'm not sure what exactly you mean by this. If the only allowed values
are "none", "variable_shadowing" and "all", how is the behaviour for
those going to change if we make it a list for 9.5?
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailin
es my issues. Thanks for
your work here.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
201 - 300 of 661 matches
Mail list logo
