On Sat, 2007-01-06 at 17:06 -0500, Bruce Momjian wrote:
I saw no replies to this.
Me neither.
I take it that means its a very good idea and we should add a TODO
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of
On Sat, 2007-01-06 at 21:32 -0500, Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
On Saturday 06 January 2007 16:36, Simon Riggs wrote:
snip
BEGIN;
CREATE TABLE foo...
INSERT INTO foo--uses WAL
COPY foo.. --no WAL
INSERT INTO foo--uses WAL
COPY foo.. --no WAL
On Sat, 2007-01-06 at 13:05 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Presumably you could put extra grammar rules in to throw errors when you
see FROM NULLS FIRST?
It'll throw an error just fine without any extra rules, because there
won't be any production allowing
On Sat, 2007-01-06 at 16:29 -0500, Bruce Momjian wrote:
The issue is that the _hold_ patches are for patches that arrived after
feature freeze. The patches that arrived after 8.2 was released don't
go in there because it might cause confusion.
Right, which is why I'm pointing it out; they
Hello,
PostgreSQL allow only catch exception (elevel ERROR). SQL/PSM requires that
warnings are catchable too. Simply solution's is adding one callback to
error's processing of errors on level WARNING.
typedef struct WarningHandlerCallback
{
bool(*callback) (void *arg,
On Sat, 2007-01-06 at 21:18 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
The rule is: if the relfilenode for a table is new in this transaction
(and therefore the whole things will be dropped at end-of-transaction)
then *all* COPY commands are able to avoid writing WAL
Simon Riggs [EMAIL PROTECTED] writes:
On Sat, 2007-01-06 at 21:18 -0500, Tom Lane wrote:
Uh ... what in the world has an active portal got to do with it?
I think you've confused snapshot considerations with crash recovery.
The patch sets HEAP_XMIN_COMMITTED on all of the rows loaded by COPY
On Sat, 2007-01-06 at 16:08 -0500, Bruce Momjian wrote:
I have looked over this patch, and it completes part of this TODO item:
o Add SET PERFORMANCE_TIPS option to suggest INDEX, VACUUM, VACUUM
ANALYZE, and CLUSTER
It involves a patch to the backend, and a /contrib
Hello,
SQL/PSM default for SQL procedures are SECURITY DEFINER (like views), but
PostgreSQL default is SECURITY CALLLER. Is acceptable to define security
flag in dependency to used language?
Regards
Pavel Stehule
_
Najdete si
Bruce Momjian wrote:
The problem there is that the web site references these, so changing the
URL for every release is odd,
Not a problem though - it's trivial for us to update whatever webpages
link to it.
plus right now both queues are for 8.3.
Well, yeah - that's why it's
On Sun, 2007-01-07 at 09:59 +0100, Pavel Stehule wrote:
PostgreSQL allow only catch exception (elevel ERROR). SQL/PSM requires that
warnings are catchable too. Simply solution's is adding one callback to
error's processing of errors on level WARNING.
Exceptions are run within their own
On Sun, 2007-01-07 at 09:59 +0100, Pavel Stehule wrote:
PostgreSQL allow only catch exception (elevel ERROR). SQL/PSM requires
that
warnings are catchable too. Simply solution's is adding one callback to
error's processing of errors on level WARNING.
Exceptions are run within their own
I am putting together searches on the catalog info and came up with a
select that was rather slow and I noticed that in the explain analyze
there is a sort step on one of the left joins which I don't think
belongs there.
I found the small error in my query (using tl.oid instead of tr.oid and
On solaris 10U2 using the Sun compiler we get segmentation faults in
nearly all of the ECPG regression tests on a 64bit built. the resulting
cores look similiar to:
Current function is ECPGget_variable
91 var-pointer = va_arg(APREF, char *);
(dbx) where
=[1] ECPGget_variable(ap =
On Sun, Jan 07, 2007 at 12:42:06AM -0500, Bruce Momjian wrote:
Joshua D. Drake wrote:
On Sat, 2007-01-06 at 23:38 -0500, Tom Lane wrote:
Everyone using these tools knows about the two-pass behavior.
No, not everyone knows. In fact I would argue that most do not know. It
isn't
On Sun, 2007-01-07 at 03:53 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Sat, 2007-01-06 at 21:18 -0500, Tom Lane wrote:
Uh ... what in the world has an active portal got to do with it?
I think you've confused snapshot considerations with crash recovery.
The patch
On Sun, Jan 07, 2007 at 11:46:29AM +, Simon Riggs wrote:
On Sun, 2007-01-07 at 03:53 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
The patch sets HEAP_XMIN_COMMITTED on all of the rows loaded by COPY as
well.
I think you just talked yourself out of getting this
On Sun, 2007-01-07 at 11:20 +0100, Pavel Stehule wrote:
On Sun, 2007-01-07 at 09:59 +0100, Pavel Stehule wrote:
PostgreSQL allow only catch exception (elevel ERROR). SQL/PSM requires
that
warnings are catchable too. Simply solution's is adding one callback to
error's processing of
On Sun, 2007-01-07 at 12:59 +0100, Martijn van Oosterhout wrote:
On Sun, Jan 07, 2007 at 11:46:29AM +, Simon Riggs wrote:
On Sun, 2007-01-07 at 03:53 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
The patch sets HEAP_XMIN_COMMITTED on all of the rows loaded by COPY as
On 1/7/07, Bruce Momjian [EMAIL PROTECTED] wrote:
I have looked over this patch,
Thanks
I think we have to decide if we want this, and whether it should be in
/contrib or fully integrated into the backend.
Well, as already said, the plugin architecture gives others a way to develop
and
On 1/7/07, Gurjeet Singh [EMAIL PROTECTED] wrote:
contrib/pg_advise_index/sample_error_messages.txt also shows an
interesting usage, where advise_index is actually a VIEW with a RULE that
redirects INSERTs into another advise_index_data table.
Also, the DDL for the advise_index table can be
Does the PSM warning error handler run in the same transaction or a
separate subtransaction? Can transaction execution continue afterwards?
It's depend. Continue and exit warning handlers run in the same
transaction,
undo handler has separate subtransaction. It works well. For
Pavel Stehule wrote:
SQL/PSM default for SQL procedures are SECURITY DEFINER (like views),
I can't find this in the standard. Where did you get this information?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
On Sun, Jan 07, 2007 at 12:42:06AM -0500, Bruce Momjian wrote:
Joshua D. Drake wrote:
On Sat, 2007-01-06 at 23:38 -0500, Tom Lane wrote:
Everyone using these tools knows about the two-pass behavior.
No, not everyone
Pavel Stehule [EMAIL PROTECTED] writes:
PostgreSQL allow only catch exception (elevel ERROR). SQL/PSM requires that
warnings are catchable too.
What in the world does it mean to catch a warning? If your intention
is to process arbitrary user-defined code while inside the error
subsystem, I
Pavel Stehule [EMAIL PROTECTED] writes:
SQL/PSM default for SQL procedures are SECURITY DEFINER (like views), but
PostgreSQL default is SECURITY CALLLER. Is acceptable to define security
flag in dependency to used language?
I'd vote no, even if Peter is wrong and you're right about what the
Pavel Stehule wrote:
SQL/PSM default for SQL procedures are SECURITY DEFINER (like views),
I can't find this in the standard. Where did you get this information?
--
Jim Melton, SQL's stored procedures, page 43,
next:
blom98sqlpsm:
3.3.1 Access rights to data
By default, the stored
Simon Riggs [EMAIL PROTECTED] writes:
On Sun, 2007-01-07 at 03:53 -0500, Tom Lane wrote:
I think you just talked yourself out of getting this patch applied.
Maybe; what would be your explanation?
The main reason is that you were guilty of false advertising. This
patch was described as being
I wrote:
... The active-portal kluge that you've just
mentioned is nothing but a kluge, proving that you thought of some cases
where it would fail. But I doubt you thought of everything.
BTW, a sufficient counterexample for that kluge is that neither SPI or
SQL-function execution use a
Bruce Momjian [EMAIL PROTECTED] writes:
Martijn van Oosterhout wrote:
I don't know enough about the relevent tool to know if they actually
generate a warning about whether they need to be rerun. In any case it
seems a much better approach to simply run it again when needed rather
than
What is problem? ANSI SQL has different model of handling exception than
postgresql. It doesn't distinguishes between warnings and exception. Simply
some sqlstate clases are reservated for warnings and other's for exception.
But all sqlstate's (without '0') can be handled via any CONTINUE,
jackal's builds have been failing since xml.c started using
xmlSaveToBuffer. It turns out that xmlSaveToBuffer is not yet
implemented in the version of libxml2 that comes with OS X (10.4.8), but
it is being implicitly defined during the build.
The version of libxml2 on jackal is 2.6.21, but
Pavel Stehule [EMAIL PROTECTED] writes:
SQL/PSM default for SQL procedures are SECURITY DEFINER (like views),
but
PostgreSQL default is SECURITY CALLLER. Is acceptable to define security
flag in dependency to used language?
I'd vote no, even if Peter is wrong and you're right about what
Shane Ambler [EMAIL PROTECTED] writes:
I am putting together searches on the catalog info and came up with a
select that was rather slow and I noticed that in the explain analyze
there is a sort step on one of the left joins which I don't think
belongs there.
Well, it's certainly necessary
On Sun, 2007-01-07 at 11:14 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Sun, 2007-01-07 at 03:53 -0500, Tom Lane wrote:
I think you just talked yourself out of getting this patch applied.
Maybe; what would be your explanation?
The main reason is that you were guilty
On Sun, 2007-01-07 at 11:29 -0500, Tom Lane wrote:
I wrote:
... The active-portal kluge that you've just
mentioned is nothing but a kluge, proving that you thought of some cases
where it would fail. But I doubt you thought of everything.
BTW, a sufficient counterexample for that kluge
Tom Lane wrote:
Perhaps even more to the point, what makes you think that someone
will notice the warning? If the docs build is one step in an
automated build process, this seems unlikely.
Taking a closer look, it's pretty much guaranteed that no one will see
them, because the targets they
It occurs to me that we don't need to write full page writes on newly extended
pages. Is that optimization in the code already? I would check except I'm not
even sure where to look for it.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end
Tom Lane wrote:
Shane Ambler [EMAIL PROTECTED] writes:
I am putting together searches on the catalog info and came up with a
select that was rather slow and I noticed that in the explain analyze
there is a sort step on one of the left joins which I don't think
belongs there.
Well, it's
Shane Ambler [EMAIL PROTECTED] writes:
Tom Lane wrote:
It seems clear to me that we ought not impose a bias unless the join
type is such that both directions of hashing are feasible.
I think that the selected sort (or at least the merge join) is incorrect
- the column sorted (or both
Pavel Stehule [EMAIL PROTECTED] writes:
What is problem? ANSI SQL has different model of handling exception than
postgresql. It doesn't distinguishes between warnings and exception. Simply
some sqlstate clases are reservated for warnings and other's for exception.
But all sqlstate's
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
Perhaps even more to the point, what makes you think that someone
will notice the warning? If the docs build is one step in an
automated build process, this seems unlikely.
Taking a closer look, it's pretty much guaranteed that no
Gregory Stark [EMAIL PROTECTED] writes:
It occurs to me that we don't need to write full page writes on newly extended
pages. Is that optimization in the code already? I would check except I'm not
even sure where to look for it.
Look for XLOG_HEAP_INIT_PAGE ... I suspect there are other cases
On Sun, 7 Jan 2007, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
Perhaps even more to the point, what makes you think that someone
will notice the warning? If the docs build is one step in an
automated build process, this seems unlikely.
Taking a closer
Peter Eisentraut wrote:
Tom Lane wrote:
Perhaps even more to the point, what makes you think that someone
will notice the warning? If the docs build is one step in an
automated build process, this seems unlikely.
Taking a closer look, it's pretty much guaranteed that no one will see
Pavel Stehule [EMAIL PROTECTED] writes:
What is problem? ANSI SQL has different model of handling exception than
postgresql. It doesn't distinguishes between warnings and exception.
Simply
some sqlstate clases are reservated for warnings and other's for
exception.
But all sqlstate's
46 matches
Mail list logo
