Hello
regress tests fails:
plancache... ok
limit... ok
plpgsql ... ok
copy2... ok
temp ... FAILED
domain ... ok
rangefuncs ... ok
pr
+02:00 Pavel Stehule :
> Hello
>
> regress tests fails:
>
> plancache... ok
> limit... ok
> plpgsql ... ok
> copy2... ok
> temp ... FAILED
> d
and there a few too long lines
Regards
Pavel
2014-06-24 18:40 GMT+02:00 Pavel Stehule :
> postgres=# select version();
>
> version
>
> -
> PostgreSQL 9.5devel on x86
2014-06-24 18:43 GMT+02:00 Josh Berkus :
> On 06/23/2014 03:52 PM, Andres Freund wrote:
> > On 2014-06-23 13:19:47 -0700, Kevin Grittner wrote:
> > which already seems less clear (because the transaction belongs
> > to idle)
> >>
> >> I have no idea what that means.
> >
> > It's "idle_in_t
2014-06-24 19:45 GMT+02:00 Sergey Muraviov :
> Hi.
>
> Is there any problem with the patch?
>
I tested it and I had not any issue with last version
So, please, commit it
Regards
Pavel
>
>
> 2014-06-17 0:21 GMT+04:00 Greg Stark :
>
> On Mon, Jun 16, 2014 at 9:05 PM, Robert Haas
>> wrote:
>>
hat you would
I am sending updated patch - buggy statement is printed via more logical
psql_error function instead printf
Regards
Pavel
>
>
>
> On Wed, Jun 4, 2014 at 9:52 PM, Pavel Stehule
> wrote:
>
>>
>>
>>
>> 2014-06-04 18:16 GMT+02:00 Peter E
eattr (or T)
>
fixed
>
>
> (9)
> + printf(_("\nEnvironment options:\n"));
>
> should be ""Environment variables". And this section lacks description
> for Windows, such as:
>
> + printf(_(" NAME=VALUE [NAME=VALUE] psql
2014-06-26 8:22 GMT+02:00 Samrat Revagade :
> > I am sending updated patch - buggy statement is printed via more logical
> psql_error function instead printf
>
> Thank you for updating patch, I really appreciate your efforts.
>
> Now, everything is good from my side.
> * it apply cleanly to the cu
Hello all,
today I had to work with one slow query - when I checked different
scenarios I found a dependency on work_mem size - but it is atypical -
bigger work_mem increased query execution 31 minutes (600MB work mem) and 1
minute (1MB).
db_kost07e2d9cdmg20b1takpqntobo6ghj=# set work_mem to '600
2014-06-26 15:26 GMT+02:00 MauMau :
> Hello,
>
> From: "Pavel Stehule"
>
>> fixed
>>
>
> Thank you. All is fine.
>
>
>
> should be ""Environment variables". And this section lacks description
>>> for Windows, such as
Hello
I recheck this patch
1. applied cleanly and compilation was without warnings and errors
2. all tests was passed ok
3. documentation was rebuild without issues
4. I don't see any issue in code quality - it is well commented, well
formatted, with regress tests
It is ready for commit
Regards
Hello
thank you Peter, so now only setting for MS Windows is missing?
Regards
Pavel
2014-06-26 21:57 GMT+02:00 Petr Jelinek :
> Hello,
>
> I went through the patch, seems mostly fine, I adjusted some wording,
> removed the default .pgpass file info since it's not accurate, and replaced
> coup
Hello
I modified description of setting system variables in dependency on O.S.
Regards
Pavel
2014-06-27 8:54 GMT+02:00 Pavel Stehule :
> Hello
>
> thank you Peter, so now only setting for MS Windows is missing?
>
> Regards
>
> Pavel
>
>
> 2014-06-26 21:57 GMT+
Hello
I am sending small patch, that allows ignore nulls in row_to_json function.
It allow significant size reduction of generated JSON documents.
Regards
Pavel
2014-05-25 7:53 GMT+02:00 Pavel Stehule :
> Hello
>
> In Czech Postgres mailing list was user request for serializatio
Hello
rebase for 9.5
test:
\pset linestyle unicode \pset border 2
\pset unicode_header_linestyle double
\l
Regards
Pavel
2014-03-11 21:17 GMT+01:00 Pavel Stehule :
> Hello
>
> I had to reduce allowed line style to single or double, because unicode
> allows only combination s
Hi
2014-06-29 0:48 GMT+02:00 MauMau :
> From: "Pavel Stehule"
>
> I modified description of setting system variables in dependency on O.S.
>>
>
> Thank you, it's almost OK. As mentioned in my previous mail, I think
> "determines" should be
2014-06-29 13:35 GMT+02:00 MauMau :
> Thanks, I marked it as ready for committer. I hope Fujii san or another
> committer will commit this, refining English expression if necessary.
>
sure
Thank you very much
Regards
Pavel
>
> Regards
> MauMau
>
>
2014-06-29 15:24 GMT+02:00 Abhijit Menon-Sen :
> At 2014-06-29 20:35:04 +0900, maumau...@gmail.com wrote:
> >
> > Thanks, I marked it as ready for committer. I hope Fujii san or
> > another committer will commit this, refining English expression if
> > necessary.
>
> Since it was just a matter of
2014-06-30 8:17 GMT+02:00 Rajeev rastogi :
> On 26 June 2014 11:53, Samrat Revagade Wrote:
>
>
>
> >> I am sending updated patch - buggy statement is printed via more
> logical psql_error function instead printf
>
>
>
> >Thank you for updating patch, I really appreciate your efforts.
>
>
>
> >Now
2014-06-29 21:09 GMT+02:00 Tom Lane :
> Vik Fearing writes:
> > On 06/21/2014 10:11 PM, Pavel Stehule wrote:
> >> Is any reason or is acceptable incompatible change CONNECTION_LIMIT
> >> instead CONNECTION LIMIT? Is decreasing parser size about 1% good enough
>
2014-06-30 11:20 GMT+02:00 Rajeev rastogi :
> On 30 June 2014 12:24, Pavel Stehule Wrote:
>
>
>
> >>I have reviewed this patch. Please find my review comments below:
>
> >>1. Command start-up option (e.g. -a/--echo-all for --ECHO=all), for
> new functio
s ready for committer if you make the above corrections.
>
> At some point, you should probably also update your --help-variables
> patch to add this new value to the description of ECHO.
>
I have it in TODO. But I don't would to introduce a dependency between
these patches - so wh
2014-06-30 12:38 GMT+02:00 Abhijit Menon-Sen :
> If I understand correctly, the design of this patch has already been
> considered earlier and rejected. So I guess the patch should also be
> marked rejected?
>
I didn't find a related message.
?
Regards
Pavel
>
> -- Abhijit
>
2014-07-01 8:16 GMT+02:00 Rajeev rastogi :
> On 30 June 2014 22:50, Pavel Stehule Wrote:
>
> 2014-06-30 12:38 GMT+02:00 Abhijit Menon-Sen :
>
> >>If I understand correctly, the design of this patch has already been
> >>considered earlier and rejected. So I
2014-07-01 8:29 GMT+02:00 Amit Kapila :
> On Tue, Jul 1, 2014 at 11:46 AM, Rajeev rastogi
> wrote:
> > On 30 June 2014 22:50, Pavel Stehule Wrote:
> >
> > >I didn't find a related message.
> > >?
> >
> > I think there have been some confusion
2014-07-01 10:38 GMT+02:00 Rajeev rastogi :
> On 01 July 2014 12:26, Pavel Stehule Wrote:
>
>
>
> >>Have you checked the discussion in Developer meeting notes. Please
>
> >>check the same at below link:
>
> >>
> http://wiki.postgresql.org/wiki/PgCo
Hi
2014-07-09 7:07 GMT+02:00 Fujii Masao :
> On Mon, Jun 30, 2014 at 8:33 PM, Pavel Stehule
> wrote:
> >
> >
> >
> > 2014-06-30 13:01 GMT+02:00 Abhijit Menon-Sen :
> >
> >> At 2014-06-30 12:48:30 +0200, pavel.steh...@gmail.com wrote:
> >
2014-07-09 14:39 GMT+02:00 Fujii Masao :
> On Wed, Jul 9, 2014 at 9:06 PM, Pavel Stehule
> wrote:
> > Hi
> >
> >
> > 2014-07-09 7:07 GMT+02:00 Fujii Masao :
> >
> >> On Mon, Jun 30, 2014 at 8:33 PM, Pavel Stehule >
> >> wrote:
> >&g
2014-07-10 7:32 GMT+02:00 Fujii Masao :
> On Wed, Jul 9, 2014 at 9:44 PM, Pavel Stehule
> wrote:
> >> Barring any objection, I will commit this patch except tab-completion
> >> part.
>
> Committed.
>
Thank you very much
>
> > It can be a second discuss
Hello
here is a proposed patch - autocomplete for known psql variable content
Regards
Pavel
2014-07-10 9:50 GMT+02:00 Pavel Stehule :
>
>
>
> 2014-07-10 7:32 GMT+02:00 Fujii Masao :
>
> On Wed, Jul 9, 2014 at 9:44 PM, Pavel Stehule
>> wrote:
>> >> Barri
2014-07-15 11:29 GMT+02:00 Fujii Masao :
> On Thu, Jul 10, 2014 at 9:56 PM, Pavel Stehule
> wrote:
> > Hello
> >
> > here is a proposed patch - autocomplete for known psql variable content
>
> Even after applying the patch, the following psql variables wer
2014-07-15 12:07 GMT+02:00 Fujii Masao :
> On Tue, Jul 15, 2014 at 7:01 PM, Pavel Stehule
> wrote:
> >
> >
> >
> > 2014-07-15 11:29 GMT+02:00 Fujii Masao :
> >
> >> On Thu, Jul 10, 2014 at 9:56 PM, Pavel Stehule >
> >> wrote:
> >
2014-07-16 10:04 GMT+02:00 Petr Jelinek :
> On 08/07/14 02:14, Tom Lane wrote:
>
>> Petr Jelinek writes:
>>
>>> here is a patch implementing varwidth_bucket (naming is up for
>>> discussion) function which does binning with variable bucket width.
>>>
>>
>> I didn't see any discussion of the namin
Hi
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.
This check should not be integrated to function validation directly.
We can integrate it to plpgsql_check
Regards
Pavel
2014-07-21 22:56 GMT+02:0
2014-07-22 8:52 GMT+02:00 Marko Tiikkaja :
> 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? T
Hi Tomas
2014-07-22 23:20 GMT+02:00 Tomas Vondra :
> On 28.6.2014 21:29, Pavel Stehule wrote:
> > Hello
> >
> > rebase for 9.5
> >
> > test:
> > \pset linestyle unicode \pset border 2
> > \pset unicode_header_linestyle double
> >
> > \l
2014-07-23 8:38 GMT+02:00 Tomas Vondra :
> On 23 Červenec 2014, 7:36, Pavel Stehule wrote:
> >
> > updated version is in attachment
>
> OK, thanks. The new version seems OK to me.
>
Thank you
Pavel
>
> Tomas
>
>
Hi
2014-07-24 3:49 GMT+02:00 Charlie Holleran :
> postgres has fantastic date-time parsing. I've tried some Java libraries
> that advertise amazing time parsing. But nothing seems to match postgres's
> time parsing. I started peeking through the source to find a reference to
> a library that
Hello
2014-07-26 19:14 GMT+02:00 Marko Tiikkaja :
> 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 THE
Hi
2014-07-26 20:39 GMT+02:00 Marko Tiikkaja :
> 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
2014-07-28 19:27 GMT+02:00 Marti Raudsepp :
> On Mon, Jul 28, 2014 at 6:24 PM, Kevin Grittner wrote:
> > Do you have some other suggestion? Keep in mind that it must allow
> > the code which will *generate* the transition tables to know
> > whether any of the attached triggers use a given transi
2014-07-29 9:41 GMT+02:00 Marti Raudsepp :
> On Tue, Jul 29, 2014 at 9:49 AM, Pavel Stehule
> wrote:
> > I dislike this proposal - it is strongly inconsistent with current
> trigger
> > design
>
> The real point I was trying to convey (in my previous email) is that
>
Hi
2014-07-30 10:22 GMT+02:00 Etsuro Fujita :
> (2014/07/29 0:58), Robert Haas wrote:
>
>> On Fri, Jul 25, 2014 at 3:39 AM, Albe Laurenz
>> wrote:
>>
>>> Shigeru Hanada wrote:
>>>
* Naming of new behavior
You named this optimization "Direct Update", but I'm not sure that
this is
Hi
plpgsql has zero optimization for this kind of functions. It is best glue
for SQL statements and relative bad for high expensive numeric
calculations. It is very simple AST interpret only.
Try to use PLPerl, PLPython, PLLua instead for this purposes.
Pavel
2014-08-04 22:48 GMT+02:00 testman
Hi
I returned to this issue and maybe I found a root issue. It is PL/pgSQL
implicit IO cast
Original text:
postgres=# DO LANGUAGE plpgsql $$ DECLARE n real;
DECLARE f integer;
BEGIN
FOR f IN 1..1000 LOOP
if 0=0 then
n = SQRT (f);
end if;
END LOOP;
RAISE NOTICE 'Result => %',n;
END $$;
NOTICE
lt => 3162.28
DO
Time: 5787.797 ms
2014-08-06 21:41 GMT+02:00 Pavel Stehule :
> Hi
>
> I returned to this issue and maybe I found a root issue. It is PL/pgSQL
> implicit IO cast
>
> Original text:
>
> postgres=# DO LANGUAGE plpgsql $$ DECLARE n real;
>
> DECLARE
2014-08-06 22:07 GMT+02:00 James Cloos :
> > "ST" == Shaun Thomas writes:
>
> ST> That said, the documentation here says FLOAT4 is an alias for REAL,
> ST> so it's somewhat nonintuitive for FLOAT4 to be so much slower than
> ST> FLOAT8, which is an alias for DOUBLE PRECISION.
>
> There are so
Hello
updated version patch in attachment
2014-08-05 13:31 GMT+02:00 Fujii Masao :
> On Wed, Jul 16, 2014 at 4:34 AM, Pavel Stehule
> wrote:
> >
> >
> >
> > 2014-07-15 12:07 GMT+02:00 Fujii Masao :
> >
> >> On Tue, Jul 15,
2014-08-07 7:10 GMT+02:00 Fujii Masao :
> On Thu, Aug 7, 2014 at 6:26 AM, Pavel Stehule
> wrote:
> > Hello
> >
> > updated version patch in attachment
>
> Thanks! But ISTM you forgot to attached the patch.
>
grr .. I am sorry
>
> >> +/* all
Hi
2014-08-08 13:58 GMT+02:00 Fujii Masao :
> On Fri, Aug 8, 2014 at 4:31 AM, Pavel Stehule
> wrote:
> >
> >
> >
> > 2014-08-07 7:10 GMT+02:00 Fujii Masao :
> >
> >> On Thu, Aug 7, 2014 at 6:26 AM, Pavel Stehule
> >> wrote:
> >
Hi
2014-08-09 10:20 GMT+02:00 Guillaume Lelarge :
> Hi,
>
> Le 9 août 2014 05:57, "Ramirez, Danilo" a
> écrit :
> >
> > Thanks to all for the great info. We are new to postgresql and this
> discussion has both instructed us and increased our respect for the
> database and the community.
> >
>
2014-08-11 19:52 GMT+02:00 Tom Lane :
> Robert Haas writes:
> > On Fri, Aug 8, 2014 at 9:34 PM, Peter Eisentraut
> wrote:
> >> What is the point of that change?
>
> > I think the output could justly be criticized for making it
> > insufficiently clear that the parenthesized text is, in fact, the
2014-08-11 14:59 GMT+02:00 Fujii Masao :
> On Sat, Aug 9, 2014 at 4:16 AM, Pavel Stehule
> wrote:
> > Hi
> >
> >
> > 2014-08-08 13:58 GMT+02:00 Fujii Masao :
> >
> >> On Fri, Aug 8, 2014 at 4:31 AM, Pavel Stehule
> >> wrote:
> >&g
> >>
> >> Oh, just revived that code.
> >
> >
> > yes, It is looking well
>
> Ok, committed!
>
super
thank you very much
Regards
Pavel
>
> Regards,
>
> --
> Fujii Masao
>
2014-08-12 15:09 GMT+02:00 Fabien COELHO :
>
> Hello,
>
>
> - 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.
>>
>
> Hmmm. I had to read the code to check it, a
2014-08-12 19:14 GMT+02:00 Fabien COELHO :
>
> one note: this patch can enforce a compatibility issues - a partially
>> broken functions, where some badly written RAISE statements was executed
>> newer.
>>
>
> I am not against this patch, but it should be in extra check probably ??
>>
>
> I'm no
Hello
I was asked about possibility to show a lock time of slow queries.
I proposed a design based on log line prefix, but it was rejected.
Any idea how to show a lock time in some practical form together with
logged slow query?
Regards
Pavel
Hi
2014-08-13 6:18 GMT+02:00 Michael Paquier :
> On Wed, Aug 13, 2014 at 4:59 AM, Pavel Stehule
> wrote:
> > Any idea how to show a lock time in some practical form together with
> logged
> > slow query?
>
> Doing a join on pg_stat_activity and pg_locks is not going
2014-08-13 7:19 GMT+02:00 Tom Lane :
> Michael Paquier writes:
> > Doing a join on pg_stat_activity and pg_locks is not going to help
> > much as you could only get the moment when query has started or its
> > state has changed. Have you thought about the addition of a new column
> > in pg_locks
2014-08-13 11:14 GMT+02:00 MauMau :
> From: "Pavel Stehule"
>
> There are two relative independent tasks
>>
>> a) monitor and show total lock time of living queries
>>
>> b) monitor and log total lock time of executed queries.
>>
>> I am
2014-08-13 13:59 GMT+02:00 MauMau :
> From: "Pavel Stehule"
>
> isn't it too heavy?
>>
>
> Are you concerned about the impactof collection overhead on the queries
> diagnosed? Maybe not light, but I'm optimistic. Oracle has the track
> record of
2014-08-13 15:22 GMT+02:00 MauMau :
> From: "Pavel Stehule"
>
>> 2014-08-13 13:59 GMT+02:00 MauMau :
>>
>>> Are you concerned about the impactof collection overhead on the queries
>>>
>>> diagnosed? Maybe not light, but I'm optimis
2014-08-08 2:13 GMT+02:00 Josh Berkus :
> On 08/07/2014 04:48 PM, Tom Lane wrote:
> > plpgsql is not efficient at all about coercions performed as a side
> > effect of assignments; if memory serves, it always handles them by
> > converting to text and back. So basically the added cost here came
>
casting
* possible small simplification of plpgsql with two benefits:
** reduce performance impact of hidden IO cast
** reduce possible issues with type transformation via hidden IO cast
Comments, notes?
Regards
Pavel Stehule
2014-08-14 15:11 GMT+02:00 Alvaro Herrera :
> Heikki Linnakangas wrote:
> > On 08/14/2014 06:53 AM, Joachim Wieland wrote:
> > >I'm seeing an assertion failure with "pg_dump -c --if-exists" which is
> > >not ready to handle BLOBs it seems:
> > >
> > >pg_dump: pg_backup_archiver.c:472: RestoreArchi
om the DROP query.
>
I am sending two patches
first is fast fix
second fix is implementation of Heikki' idea.
> - Heikki
>
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.post
2014-08-18 7:42 GMT+02:00 Alvaro Herrera :
> Pavel Stehule wrote:
> > 2014-08-13 15:22 GMT+02:00 MauMau :
>
> > > I didn't mean performance statistics data to be stored in database
> tables.
> > > I just meant:
> > >
> > > * pg_stat_syste
>
> - some multi-line comment style also needs fix according to the above
> documentation (link)
>
>
>
> - And I also found patch cannot be applied to current master.
>
>
>
> Regards,
>
> Ideriha, Takeshi
>
>
>
> *From:* pgsql-hackers-ow...@postg
; issues will be corrected (i have some comments only my orientation in code).
>
>
>>
>>
>> - And I also found patch cannot be applied to current master.
>>
>
> I have 9.6.2 source code. It is not correct? Where i find source code i
> should u
>
> IMHO, what would be a lot more useful than something that generates
> {read,equal,copy,out}funcs.c automatically would be something that
> just checks them for trivial errors of omission. For example, if you
> read a list of structure members from the appropriate header files and
> cross-check
Hi
2017-03-23 12:33 GMT+01:00 Alexey Kondratov :
> Hi pgsql-hackers,
>
> I'm planning to apply to GSOC'17 and my proposal consists currently of two
> parts:
>
> (1) Add errors handling to COPY as a minimum program
>
> Motivation: Using PG on the daily basis for years I found that there are
> some
>> 1) Is there anyone out of PG comunity who will be interested in such
>> project and can be a menthor?
>> 2) These two points have a general idea – to simplify work with a large
>> amount of data from a different sources, but mybe it would be better to
>> focus on the single task?
>>
>
> I spent
Hi
2017-03-25 13:41 GMT+01:00 Surafel Temesgen :
>
>
>>
>> I took a quick look through this and noted that it fails to touch
>> ruleutils.c, which means that dumping of views containing CORRESPONDING
>> certainly doesn't work.
>>
> fixed
>
>> Also, the changes in parser/analyze.c seem rather mass
Hi
fresh update - I enhanced Value node by location field as Tom proposal.
Few more regress tests.
But I found significant issue, that needs bigger fix - Surafel, please, can
you fix it.
It crash on
SELECT 0 AS x1, 1 AS a, 0 AS x2, 2 AS b, 0 AS x3, -1 AS x3
UNION ALL CORRESPONDING SELECT 4 AS
2017-03-27 13:59 GMT+02:00 Alexander Korotkov :
> On Fri, Mar 10, 2017 at 6:06 PM, Pavel Stehule
> wrote:
>
>> 2017-03-10 16:00 GMT+01:00 Alexander Korotkov
>> :
>>
>>> On Fri, Mar 10, 2017 at 5:16 PM, Stephen Frost
>>> wrote:
>>>
>
2017-03-28 9:51 GMT+02:00 Jan Kechel :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: RIPEMD160
>
>
> Hi PostgreSQL Hackers,
>
>
> I'm developing software using PostgreSQL for several years and want to
> propose a feature to improve security of (badly written?) Web-Apps.
>
> I call it 'Database Secu
Hi
I am sending a patch with changes in XMLTABLE documentation proposed by
Arjen.
Regards
Pavel
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index ba6f8dd8d2..857c56241b 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -10504,7 +10504,7 @@ SELECT xpath_exists('
2017-03-28 13:58 GMT+02:00 Surafel Temesgen :
> can you help with fixing it Pavel?
>
There must be some new preanalyze stage - you have to know result columns
before you are starting a analyze
Regards
Pavel
>
> On Mon, Mar 27, 2017 at 11:48 AM, Pavel Stehule
> wrote:
>
2017-03-28 14:18 GMT+02:00 Pavel Stehule :
>
>
> 2017-03-28 13:58 GMT+02:00 Surafel Temesgen :
>
>> can you help with fixing it Pavel?
>>
>
> There must be some new preanalyze stage - you have to know result columns
> before you are starting a analyze
>
maybe
Hi
rebased due last changes in pg_exec.c
Regards
Pavel
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index d356deb9f5..56da4d6163 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -802,6 +802,32 @@ $$ LANGUAGE plpgsql;
happen in a plain SQL comma
2017-03-28 20:29 GMT+02:00 Petr Jelinek :
> On 28/03/17 19:43, Pavel Stehule wrote:
> > Hi
> >
> > rebased due last changes in pg_exec.c
> >
>
> Thanks, I went over this and worked over the documentation/comments a
> bit (attached updated version of the patc
>
>
This proposal was here already - maybe two years ago. The psql command
parser doesn't allow any complex syntax - more - the more parameters in one
psql commands is hard to remember, hard to read.
>>>
>>> Could you please provide a link to this discussion. Probably work
we do (T1 U T2) U T3 ---> then result is correct,
but if we do T1 U (T2 U T3) ---> than it should to fail
I am not sure, if this result is expected (correct). I expect more syntax
error because corresponding by is not filled.
>
> Regards
>
> Surafel
>
>
> On Tue, Mar 2
2017-03-29 20:11 GMT+02:00 Jan Michálek :
>
>
> 2017-03-27 19:41 GMT+02:00 Jan Michálek :
>
>>
>>
>> 2017-03-23 17:26 GMT+01:00 Pierre Ducroquet :
>>
>>> The following review has been posted through the commitfest application:
>>> make installcheck-world: tested, passed
>>> Implements feature:
2017-03-30 21:43 GMT+02:00 Tom Lane :
> Pavel Stehule writes:
> > Is following use case defined in standard?
>
> > postgres=# SELECT 0 AS x1, 1 AS a, 0 AS x2, 2 AS b, 0 AS x3, -1 AS x3
> >UNION ALL CORRESPONDING BY(a,b) SELECT 4 AS b, 0 AS x4, 3 AS
&g
Hi
2017-03-30 21:55 GMT+02:00 Pavel Stehule :
>
>
> 2017-03-30 21:43 GMT+02:00 Tom Lane :
>
>> Pavel Stehule writes:
>> > Is following use case defined in standard?
>>
>> > postgres=# SELECT 0 AS x1, 1 AS a, 0 AS x2, 2 AS b, 0 AS x3, -1 AS x3
>
2017-03-31 15:00 GMT+02:00 Daniel Verite :
> Tom Lane wrote:
>
> > Thoughts?
>
> ISTM that expr is too painful to use to be seen as the
> idiomatic way of achieving comparison in psql.
>
> Among its disadvantages, it won't work on windows, and its
> interface is hard to work with due to th
2017-04-02 8:53 GMT+02:00 Fabien COELHO :
>
> Bonjour Daniel,
>
> I think that users would rather have the option to just put
>> an SQL expression behind \if.
>>
>
> Note that this is already available indirectly, as show in the
> documentation.
>
> SELECT some-boolean-expression AS okay \gset
>
2017-04-02 9:45 GMT+02:00 Fabien COELHO :
>
> Hello Pavel,
>
> For this case can be nice to have function that returns server version as
>> number some like version_num() .. 1
>>
>
> The server side information can be queried:
>
> SELECT current_setting(‘server_version_num’)
> AS server_
2017-04-02 9:45 GMT+02:00 Fabien COELHO :
>
> Hello Pavel,
>
> For this case can be nice to have function that returns server version as
>> number some like version_num() .. 1
>>
>
> The server side information can be queried:
>
> SELECT current_setting(‘server_version_num’)
> AS server_
2017-04-02 13:13 GMT+02:00 Fabien COELHO :
>
> Hello Pavel,
>
> \echo :VERSION
>>> PostgreSQL 10devel on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu
>>> 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609, 64-bit
>>>
>>> Probably some :VERSION_NUM would make some sense. See attached PoC patch.
>>> Would i
2017-04-02 18:29 GMT+02:00 Tom Lane :
> Corey Huinker writes:
> > On Mon, Jan 23, 2017 at 12:53 PM, Tom Lane wrote:
> >> This seems pretty bizarre. What's the use case? Why would it not
> >> be better to build the behavior out of other spare parts, along the
> >> lines of COALESCE or perhaps
>
2017-04-02 18:56 GMT+02:00 Fabien COELHO :
>
> Hello Tom,
>
> I'm inclined to suggest that we should require all extensions beyond the
>> boolean-literal case to be set up as a keyword followed by appropriate
>> argument(s); that seems like it's enough to prevent syntax conflicts from
>> future ad
2017-04-04 6:17 GMT+02:00 Vicky Vergara :
>
> Hello,
>
>
> When creating an extension upgrade sql script, because the function does
> not have the same parameter names and/or parameters type and/or the result
> types changes, there is the need to drop the function because otherwise the
> CREATE OR
2017-04-03 21:24 GMT+02:00 Fabien COELHO :
>
> Hello Tom,
>
> \if [select current_setting('server_version_num')::int < 11]
>>>
>>
>> I really dislike this syntax proposal.
>>
>
> It would get us into having to count nested brackets, and distinguish
>> quoted from unquoted brackets, and so on
Hi
I am still little bit unhappy with missing functionality in our generic
types.
If I write function fx(anyelement, anyelement) returns anyelement
postgres=# create or replace function fx(anyelement, anyelement) returns
anyelement
as $$ select greather($1,$2) $$ language sql;
CREATE FUNCTION
po
2017-04-04 9:53 GMT+02:00 Fabien COELHO :
>
> Hello Pavel,
>
> The expression evaluation is interesting question, but there is a
>> workaround - we can use \gset already.
>>
>
> Yes, that is a good point. It is a little bit inconvenient because it
> requires a dummy variable name each time for tes
xecution
when you change a API, then the analyze stage should be processed again -
but views are stored as post analyzed serialized data. You cannot do this
process again without source code.
Regards
Pavel
>
> Thanks
>
> ------
> *De:* Pavel Stehule
> *E
2017-04-04 22:05 GMT+02:00 Fabien COELHO :
>
> After some discussions about what could be useful since psql scripts now
> accepts tests, this patch sets a few variables which can be used by psql
> after a "front door" (i.e. actually typed by the user) query:
>
> - RESULT_STATUS: the status of the
2017-03-17 4:23 GMT+01:00 Noah Misch :
> On Sun, Mar 12, 2017 at 10:26:33PM +0100, Pavel Stehule wrote:
> > 2017-03-12 21:57 GMT+01:00 Noah Misch :
> > > On Sun, Mar 12, 2017 at 08:36:58PM +0100, Pavel Stehule wrote:
> > > > 2017-03-12 0:56 GMT+01:00 Noah Misch
501 - 600 of 5142 matches
Mail list logo
