Re: [HACKERS] DEFAULT of domain ignored in plpgsql (8.4.1)

On 21 Nov 2009, at 02:56, Josh Berkus wrote: > >> Would a patch that changes that have any chance of being accepted? Or is >> the gain (not having to repeat the DEFAULT clause, and being able to >> maintain it at one place instead of many) considered too small compared >> to the risk of breaking

[HACKERS] Proposal: USING clause for DO statement

Hello, I am still thinking, about using DO statement from psql console. I am missing any parametrisation. It could not be a problem. All pl have a support for parameters, we have a libpq function PQexecParams - so we need only some "USING" clause. I propose following syntax (and using from client

Re: [HACKERS] Proposal: USING clause for DO statement

2009/11/21 Pavel Stehule : > Hello, > > I am still thinking, about using DO statement from psql console. I am > missing any parametrisation. It could not be a problem. All pl have a > support for parameters, we have a libpq function PQexecParams - so we > need only some "USING" clause. I propose fo

Re: [HACKERS] [patch] pg_ctl init extension

On lör, 2009-11-14 at 14:50 +0100, Zdenek Kotala wrote: > Peter Eisentraut píše v so 14. 11. 2009 v 10:41 +0200: > > On tor, 2009-09-17 at 21:43 +0200, Zdenek Kotala wrote: > > > Attached patch extends pg_ctl command with init option. > > > > > > pg_ctl -D /var/lib/postgres [-s] init > > > > > >

[HACKERS] [PATCH] hstore documentation update

From: David E. Wheeler As I threatened when I reviewed hstore in the last two commit fests, I've finally seen may way to edit the documentation. This is mostly word-smithing, making sure that all `>`s are encoded, making sure that various text is properly tagged with `` and `` tags, plus an extra

Re: [HACKERS] Proposal: USING clause for DO statement

Pavel Stehule wrote: What do you thing about this proposal? I think it's premature. Before we start adding bells and whistles to the feature, let's give it a turn in the field. One possible problem: what type would these anonymous params be? (And, BTW, don't kid yourself that there w

Re: [HACKERS] Proposal: USING clause for DO statement

2009/11/21 Andrew Dunstan : > > > Pavel Stehule wrote: >> >> What do you thing about this proposal? >> >> >> > > I think it's premature. Before we start adding bells and whistles to the > feature, let's give it a turn in the field. why? It thing so not. My opinion - it is incomplete. It has simila

Re: [HACKERS] Proposal: USING clause for DO statement

Pavel Stehule wrote: p.s. Maybe it is premature - We had to live with EXECUTE (without USING clause) twelve years. But an life should be comfortable. I don't would to wait twelve years :) I think you should take heed of Tom's words: I think adding onto DO capabilities is something we co

Re: [HACKERS] Proposal: USING clause for DO statement

Pavel Stehule writes: > 2009/11/21 Andrew Dunstan : >> One possible problem: what type would these anonymous params be? > It is solved long time - without specification, any parameter is > 'unknown text'. Nonsense. We do have the ability to infer parameter types when parsing a SQL statement. Th

Re: [HACKERS] DEFAULT of domain ignored in plpgsql (8.4.1)

Josh Berkus writes: > (2) this change, while very useful, does change what had been a simple > rule ("All variables are NULL unless specifically set otherwise") into a > conditional one ("All variables are NULL unless set otherwise OR unless > they are declared as domain types with defaults"). Do

Re: [HACKERS] DEFAULT of domain ignored in plpgsql (8.4.1)

On Sat, Nov 21, 2009 at 7:26 AM, Josh Berkus wrote: > > > Would a patch that changes that have any chance of being accepted? Or is > > the gain (not having to repeat the DEFAULT clause, and being able to > > maintain it at one place instead of many) considered too small compared > > to the risk o

Re: [HACKERS] xpath_table equivalent

I wrote: The nice thing about XMLTABLE is that it adds xquery support. I think the majority of xquery engines seem to be written in Java. XQuilla is C++. I'm not sure if our licensing is compatible, but it I would love the irony of using Berkeley DB XML (formerly Sleepycat) now that its ow

Re: [HACKERS] Proposal: USING clause for DO statement

2009/11/21 Tom Lane : > Pavel Stehule writes: >> 2009/11/21 Andrew Dunstan : >>> One possible problem: what type would these anonymous params be? > >> It is solved long time - without specification, any parameter is >> 'unknown text'. > > Nonsense. > ok. > We do have the ability to infer paramet

Re: [HACKERS] Proposal: USING clause for DO statement

I don't see point in having parameters for DO as an utility command. If you need to reuse some value you can define those variables at the beginning of code block in the language itself (in DECLARE section in plpgsql for example), defining them in outer SQL command does not really help anything

Re: [HACKERS] Proposal: USING clause for DO statement

2009/11/21 Petr Jelinek : > I don't see point in having parameters for DO as an utility command. If you > need to reuse some value you can define those variables at the beginning of > code block in the language itself (in DECLARE section in plpgsql for > example), defining them in outer SQL command

Re: [HACKERS] Proposal: USING clause for DO statement

Pavel Stehule wrote: I would to use this statement for some non trivial maintenance tasks - and I would to use external parameter (from command line). My question is - what is a good way for passing some value (from command line) to DO statement body? I accept any mechanism. See my earlie

[HACKERS] Hot standby and removing VACUUM FULL

VACUUM FULL does a peculiar hack: once it's done moving tuples, and before it truncates the relation, it calls RecordTransactionCommit to mark the transaction as committed in clog and WAL, but the transaction is still kept open in proc array. After it's done with truncating and other cleanup, norma

Re: [HACKERS] Proposal: USING clause for DO statement

On Sat, Nov 21, 2009 at 12:36 PM, Andrew Dunstan wrote: >> Perhaps part of the problem is that psql can't interpolate its variable >> into strings. Solving that might lessen the impetus for this, and have other >> uses besides. +1! This would have a _lot_ of uses. merlin -- Sent via pgsql-hac

Re: [HACKERS] Proposal: USING clause for DO statement

2009/11/21 Merlin Moncure : > On Sat, Nov 21, 2009 at 12:36 PM, Andrew Dunstan wrote: >>> Perhaps part of the problem is that psql can't interpolate its variable >>> into strings. Solving that might lessen the impetus for this, and have other >>> uses besides. > > +1! > > This would have a _lot_ o

Re: [HACKERS] Proposal: USING clause for DO statement

On Sat, Nov 21, 2009 at 1:24 PM, Pavel Stehule wrote: > 2009/11/21 Merlin Moncure : >> On Sat, Nov 21, 2009 at 12:36 PM, Andrew Dunstan wrote: Perhaps part of the problem is that psql can't interpolate its variable into strings. Solving that might lessen the impetus for this, and have

Re: [HACKERS] Proposal: USING clause for DO statement

2009/11/21 Merlin Moncure : > On Sat, Nov 21, 2009 at 1:24 PM, Pavel Stehule > wrote: >> 2009/11/21 Merlin Moncure : >>> On Sat, Nov 21, 2009 at 12:36 PM, Andrew Dunstan >>> wrote: > Perhaps part of the problem is that psql can't interpolate its variable > into strings. Solving that mig

Re: [HACKERS] Hot standby and removing VACUUM FULL

Heikki Linnakangas wrote: So I guess what I'm asking is: Does anyone see any show-stoppers in removing VACUUM FULL Here's the disclaimers attached to the new VACUUM REPLACE implementation from Itagaki: "We still need traditional VACUUM FULL behavior for system catalog because we cannot change

Re: [HACKERS] Proposal: USING clause for DO statement

Andrew Dunstan writes: > See my earlier comment: >> Perhaps part of the problem is that psql can't interpolate its >> variable into strings. Solving that might lessen the impetus for this, >> and have other uses besides. It seems to me that this is sliding down the wrong slope. You're basicall

Re: [HACKERS] Hot standby and removing VACUUM FULL

Heikki Linnakangas writes: > So I guess what I'm asking is: Does anyone see any show-stoppers in > removing VACUUM FULL, and does anyone want to step up to the plate and > promise to do it before release? I don't see much problem with rejecting VAC FULL in a HS master, whether or not it gets remo

Re: [HACKERS] Proposal: USING clause for DO statement

> > The main limitation of this type of approach is that it's hard to > properly quote a variable value that might contain any random character > sequence.  However, that's also true of the variable-interpolation stuff > Pavel was proposing.  In any case I don't think that "getting stuff from > psq

Re: [HACKERS] Hot standby and removing VACUUM FULL

Tom Lane wrote: > Heikki Linnakangas writes: >> So I guess what I'm asking is: Does anyone see any show-stoppers in >> removing VACUUM FULL, and does anyone want to step up to the plate and >> promise to do it before release? > > I don't see much problem with rejecting VAC FULL in a HS master, >

Re: [HACKERS] Hot standby and removing VACUUM FULL

Heikki Linnakangas writes: > Tom Lane wrote: >> I don't see much problem with rejecting VAC FULL in a HS master, >> whether or not it gets removed altogether. Why not just do that >> rather than write a lot of kluges? > Hmm. At the moment, no action is required in the master to allow hot > stand

Re: [HACKERS] Proposal: USING clause for DO statement

Pavel Stehule writes: > Hypothetically - when we are able to pass any value to DO script, then > I don't see problem. If I use Andrew's design - ${shellvar} and add it > to psql parser, then I could to write > \set par1 world > do $$ > begin > raise notice 'Helo, % and %', $1, $2; > end;

Re: [HACKERS] Proposal: USING clause for DO statement

Tom Lane wrote: In any case I don't think that "getting stuff from psql variables into a DO script" is the way to define the problem. It's "getting stuff from shell variables into a DO script" that is the real-world problem. Indeed. But setting psql variables from the command line is easy. W

Re: [HACKERS] [INTERFACES] ecpg & 8.3 -> 8.4 migration

On Fri, Nov 20, 2009 at 07:02:11PM -0500, Tom Lane wrote: > Upon poking around in the ecpg sources, I discover that it has its own > list of "unreserved" keywords and pays no attention whatsoever to the > core grammar's unreserved_keyword list. I can hardly find words to > express my dissatisfacti

Re: [HACKERS] Hot standby and removing VACUUM FULL

Tom Lane wrote: > Heikki Linnakangas writes: >> Tom Lane wrote: >>> I don't see much problem with rejecting VAC FULL in a HS master, >>> whether or not it gets removed altogether. Why not just do that >>> rather than write a lot of kluges? > >> Hmm. At the moment, no action is required in the ma

Re: [HACKERS] Proposal: USING clause for DO statement

2009/11/21 Tom Lane : > Pavel Stehule writes: >> Hypothetically - when we are able to pass any value to DO script, then >> I don't see problem. If I use Andrew's design - ${shellvar} and add it >> to psql parser, then I could to write > >> \set par1 world > >> do $$ >>   begin >>     raise notice

Re: [HACKERS] Proposal: USING clause for DO statement

On Sat, Nov 21, 2009 at 3:32 PM, Pavel Stehule wrote: > 2009/11/21 Tom Lane : >> Pavel Stehule writes: >>> Hypothetically - when we are able to pass any value to DO script, then >>> I don't see problem. If I use Andrew's design - ${shellvar} and add it >>> to psql parser, then I could to write >>

Re: [HACKERS] Hot standby and removing VACUUM FULL

Heikki Linnakangas writes: > Tom Lane wrote: >> There's no equivalent of XLogArchivingActive()? > XLogArchivingMode() == false enables us to skip WAL-logging in > operations like CLUSTER or COPY, which is a big optimization. I don't > see anything like that in Hot Standby. There is a few small th

Re: [HACKERS] Proposal: USING clause for DO statement

2009/11/21 Merlin Moncure : > On Sat, Nov 21, 2009 at 3:32 PM, Pavel Stehule > wrote: >> 2009/11/21 Tom Lane : >>> Pavel Stehule writes: Hypothetically - when we are able to pass any value to DO script, then I don't see problem. If I use Andrew's design - ${shellvar} and add it to

Re: [HACKERS] [INTERFACES] ecpg & 8.3 -> 8.4 migration

I'm pretty sure the problem I found is related to this, but I found that ecpg doesn't process booleans correctly- this was in a old version of postgres (I think it was 7.4.2).  I traced it down in the code, and there is a section that defines the values to be "yes" or "no", but then further proc

Re: [HACKERS] Hot standby and removing VACUUM FULL

Tom Lane wrote: > Heikki Linnakangas writes: >> Tom Lane wrote: >>> There's no equivalent of XLogArchivingActive()? > >> XLogArchivingMode() == false enables us to skip WAL-logging in >> operations like CLUSTER or COPY, which is a big optimization. I don't >> see anything like that in Hot Standby

Re: [HACKERS] DEFAULT of domain ignored in plpgsql (8.4.1)

Tom Lane wrote: Josh Berkus writes: (2) this change, while very useful, does change what had been a simple rule ("All variables are NULL unless specifically set otherwise") into a conditional one ("All variables are NULL unless set otherwise OR unless they are declared as domain types with defa

Re: [HACKERS] DEFAULT of domain ignored in plpgsql (8.4.1)

Gurjeet Singh wrote: On Sat, Nov 21, 2009 at 7:26 AM, Josh Berkus > wrote: However, there are some other issues to be resolved: (1) what should be the interaction of DEFAULT parameters and domains with defaults? The function's DEFAULT parameter should take precedence

[HACKERS] Ignoring white space in regression tests really a good idea?

pg_regress compares expected and actual output using "diff -w" (a/k/a --ignore-all-space). We have always done this, and I think the idea was to avoid getting a lot of useless diff noise when the only real difference is that one column value in a tabular display is wider than expected. I'm wonder

Re: [HACKERS] Ignoring white space in regression tests really a good idea?

On Nov 22, 2009, at 7:49 AM, Tom Lane wrote: > I'm thinking maybe we should remove -w. Comments? Have you tried it on the existing tests to see what happens? David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql

Re: [HACKERS] DEFAULT of domain ignored in plpgsql (8.4.1)

On lör, 2009-11-21 at 22:20 +0100, Florian G. Pflug wrote: > > I'm inclined to leave it alone. It complicates the mental model, and > > frankly attaching defaults to domains was not one of the SQL > > committee's better ideas anyway. It's *fundamentally* > > non-orthogonal. > > I've always thou

Re: [HACKERS] Partitioning option for COPY

Emmanuel Cecchet wrote: > Hi Jan, > > Here is the updated patch. > Note that the new code in trigger is a copy/paste of the before row > insert trigger code modified to use the pointers of the after row > trigger functions. Hi, ok, this version applied, compiled and ran the regression tests fine

Re: [HACKERS] UTF8 with BOM support in psql

On mån, 2009-11-16 at 22:37 +0200, Peter Eisentraut wrote: > On ons, 2009-10-21 at 13:11 +0900, Itagaki Takahiro wrote: > > Sure. Client encoding is declared in body of a file, but BOM is > > in head of the file. So, we should always ignore BOM sequence > > at the file head no matter what client en

Re: [HACKERS] Ignoring white space in regression tests really a good idea?

On Sat, Nov 21, 2009 at 16:07, David E. Wheeler wrote: > On Nov 22, 2009, at 7:49 AM, Tom Lane wrote: > >> I'm thinking maybe we should remove -w.  Comments? > > Have you tried it on the existing tests to see what happens? For me there I get: *the breaking in create_cast *various things in foreig

Re: [HACKERS] Unicode UTF-8 table formatting for psql text output

Roger Leigh writes: > Attached is an updated patch with a couple of tweaks to ensure output > is formatted and spaced correctly when border=0, which was off in the > last patch. Applied wih minor editorialization. Notably, I renamed the backwards-compatible option from "ascii-old" to "old-ascii"

Re: [HACKERS] Partitioning option for COPY

Jan Urbański wrote: o) my main concern is still valid: the design was never agreed upon. The approach of using inheritance info for automatic partitioning is, at least IMHO, too restricted. Regular INSERTs won't get routed to child tables. Data from writable CTEs won't get routed. People wanting

Re: [HACKERS] Partitioning option for COPY

Jan Urbański wrote: o) my main concern is still valid: the design was never agreed upon. The approach of using inheritance info for automatic partitioning is, at least IMHO, too restricted. Regular INSERTs won't get routed to child tables. Data from writable CTEs won't get routed. People wanting