Re: Controlling changes in plpgsql variable resolution

От

David E. Wheeler

Тема

Дата

19 октября 2009 г. в 15:55:40

Msg-id

CB66B656-C6DB-42C4-B70D-78DB0631D49F@kineticode.com

обсуждение

Ответ на

Re: Controlling changes in plpgsql variable resolution (Tom Lane)

Список

pgsql-hackers

Дерево обсуждения

Controlling changes in plpgsql variable resolution Tom Lane <tgl@sss.pgh.pa.us> 18 октября 2009 г. в 14:25:54

Re: Controlling changes in plpgsql variable resolution Simon Riggs <simon@2ndQuadrant.com> 18 октября 2009 г. в 16:46:01

Re: Controlling changes in plpgsql variable resolution Stephen Frost <sfrost@snowman.net> 19 октября 2009 г. в 11:54:51

Re: Controlling changes in plpgsql variable resolution "David E. Wheeler" <david@kineticode.com> 19 октября 2009 г. в 13:25:22

Re: Controlling changes in plpgsql variable resolution Robert Haas <robertmhaas@gmail.com> 19 октября 2009 г. в 12:36:51

Re: Controlling changes in plpgsql variable resolution "David E. Wheeler" <david@kineticode.com> 19 октября 2009 г. в 13:27:30

Re: Controlling changes in plpgsql variable resolution Stephen Frost <sfrost@snowman.net> 19 октября 2009 г. в 13:29:24

Re: Controlling changes in plpgsql variable resolution "David E. Wheeler" <david@kineticode.com> 19 октября 2009 г. в 13:42:11

Re: Controlling changes in plpgsql variable resolution Tom Lane <tgl@sss.pgh.pa.us> 19 октября 2009 г. в 13:49:54

Re: Controlling changes in plpgsql variable resolution Robert Haas <robertmhaas@gmail.com> 19 октября 2009 г. в 14:47:16

Re: Controlling changes in plpgsql variable resolution "David E. Wheeler" <david@kineticode.com> 19 октября 2009 г. в 13:53:11

Re: Controlling changes in plpgsql variable resolution "Kevin Grittner" <Kevin.Grittner@wicourts.gov> 19 октября 2009 г. в 14:05:30

Re: Controlling changes in plpgsql variable resolution Pavel Stehule <pavel.stehule@gmail.com> 19 октября 2009 г. в 14:18:02

Re: Controlling changes in plpgsql variable resolution Tom Lane <tgl@sss.pgh.pa.us> 19 октября 2009 г. в 14:51:00

Re: Controlling changes in plpgsql variable resolution "Kevin Grittner" <Kevin.Grittner@wicourts.gov> 19 октября 2009 г. в 15:09:42

Re: Controlling changes in plpgsql variable resolution Andrew Dunstan <andrew@dunslane.net> 19 октября 2009 г. в 15:14:20

Re: Controlling changes in plpgsql variable resolution Tom Lane <tgl@sss.pgh.pa.us> 19 октября 2009 г. в 15:50:20

Re: Controlling changes in plpgsql variable resolution Bruce Momjian <bruce@momjian.us> 20 октября 2009 г. в 02:41:39

Re: Controlling changes in plpgsql variable resolution Bruce Momjian <bruce@momjian.us> 20 октября 2009 г. в 03:21:46

Re: Controlling changes in plpgsql variable resolution Tom Lane <tgl@sss.pgh.pa.us> 20 октября 2009 г. в 11:33:39

Re: Controlling changes in plpgsql variable resolution Peter Eisentraut <peter_e@gmx.net> 23 октября 2009 г. в 05:28:58

Re: Controlling changes in plpgsql variable resolution Merlin Moncure <mmoncure@gmail.com> 20 октября 2009 г. в 12:53:16

Re: Controlling changes in plpgsql variable resolution Tom Lane <tgl@sss.pgh.pa.us> 20 октября 2009 г. в 13:12:27

Re: Controlling changes in plpgsql variable resolution Pavel Stehule <pavel.stehule@gmail.com> 20 октября 2009 г. в 13:13:50

Re: Controlling changes in plpgsql variable resolution Bruce Momjian <bruce@momjian.us> 20 октября 2009 г. в 14:08:02

Re: Controlling changes in plpgsql variable resolution Pavel Stehule <pavel.stehule@gmail.com> 20 октября 2009 г. в 16:40:03

Re: Controlling changes in plpgsql variable resolution "Eric B. Ridge" <ebr@tcdi.com> 19 октября 2009 г. в 16:13:04

Re: Controlling changes in plpgsql variable resolution Tom Lane <tgl@sss.pgh.pa.us> 19 октября 2009 г. в 16:46:36

Re: Controlling changes in plpgsql variable resolution "Eric B. Ridge" <ebr@tcdi.com> 19 октября 2009 г. в 18:01:17

Re: Controlling changes in plpgsql variable resolution Josh Berkus <josh@agliodbs.com> 21 октября 2009 г. в 15:00:09

Re: Controlling changes in plpgsql variable resolution Robert Haas <robertmhaas@gmail.com> 21 октября 2009 г. в 15:38:10

Re: Controlling changes in plpgsql variable resolution "David E. Wheeler" <david@kineticode.com> 21 октября 2009 г. в 15:53:20

Re: Controlling changes in plpgsql variable resolution Josh Berkus <josh@agliodbs.com> 21 октября 2009 г. в 16:09:30

Re: Controlling changes in plpgsql variable resolution Tom Lane <tgl@sss.pgh.pa.us> 21 октября 2009 г. в 16:38:53

Re: Controlling changes in plpgsql variable resolution Pavel Stehule <pavel.stehule@gmail.com> 21 октября 2009 г. в 23:06:22

Re: Controlling changes in plpgsql variable resolution Bruce Momjian <bruce@momjian.us> 9 ноября 2009 г. в 19:18:35

Re: Controlling changes in plpgsql variable resolution Josh Berkus <josh@agliodbs.com> 21 октября 2009 г. в 17:02:43

Re: Controlling changes in plpgsql variable resolution Tom Lane <tgl@sss.pgh.pa.us> 21 октября 2009 г. в 18:13:42

Re: Controlling changes in plpgsql variable resolution Josh Berkus <josh@agliodbs.com> 21 октября 2009 г. в 17:06:04

Re: Controlling changes in plpgsql variable resolution Merlin Moncure <mmoncure@gmail.com> 21 октября 2009 г. в 17:28:59

Re: Controlling changes in plpgsql variable resolution Robert Haas <robertmhaas@gmail.com> 21 октября 2009 г. в 17:51:08

Re: Controlling changes in plpgsql variable resolution Tom Lane <tgl@sss.pgh.pa.us> 21 октября 2009 г. в 18:03:34

Re: Controlling changes in plpgsql variable resolution Robert Haas <robertmhaas@gmail.com> 21 октября 2009 г. в 18:13:44

Re: Controlling changes in plpgsql variable resolution Dimitri Fontaine <dfontaine@hi-media.com> 22 октября 2009 г. в 07:05:35

Re: Controlling changes in plpgsql variable resolution Pavel Stehule <pavel.stehule@gmail.com> 22 октября 2009 г. в 07:36:25

Re: Controlling changes in plpgsql variable resolution Andrew Dunstan <andrew@dunslane.net> 22 октября 2009 г. в 11:13:11

Re: Controlling changes in plpgsql variable resolution Robert Haas <robertmhaas@gmail.com> 22 октября 2009 г. в 11:15:55

Re: Controlling changes in plpgsql variable resolution Dimitri Fontaine <dfontaine@hi-media.com> 22 октября 2009 г. в 16:13:36

Re: Controlling changes in plpgsql variable resolution "David E. Wheeler" <david@kineticode.com> 19 октября 2009 г. в 15:55:40

Re: Controlling changes in plpgsql variable resolution Tom Lane <tgl@sss.pgh.pa.us> 19 октября 2009 г. в 16:06:19

Re: Controlling changes in plpgsql variable resolution Tom Lane <tgl@sss.pgh.pa.us> 19 октября 2009 г. в 16:15:33

Re: Controlling changes in plpgsql variable resolution "David E. Wheeler" <david@kineticode.com> 19 октября 2009 г. в 16:13:50

Re: Controlling changes in plpgsql variable resolution Tom Lane <tgl@sss.pgh.pa.us> 19 октября 2009 г. в 16:23:57

Re: Controlling changes in plpgsql variable resolution "David E. Wheeler" <david@kineticode.com> 19 октября 2009 г. в 16:53:08

Could postgres be much cleaner if a future release skipped backward compatibility? Ron Mayer <rm_pg@cheapcomplexdevices.com> 19 октября 2009 г. в 18:08:54

Re: Could postgres be much cleaner if a future release skipped backward compatibility? Peter Eisentraut <peter_e@gmx.net> 20 октября 2009 г. в 02:43:34

Re: Could postgres be much cleaner if a future release skipped backward compatibility? Tom Lane <tgl@sss.pgh.pa.us> 19 октября 2009 г. в 19:45:16

Re: Could postgres be much cleaner if a future release skipped backward compatibility? Aidan Van Dyk <aidan@highrise.ca> 19 октября 2009 г. в 21:37:53

Re: Could postgres be much cleaner if a future release skipped backward compatibility? Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> 20 октября 2009 г. в 04:04:45

Re: Could postgres be much cleaner if a future release skipped backward compatibility? James Mansion <james@mansionfamily.plus.com> 25 октября 2009 г. в 07:37:14

Re: Could postgres be much cleaner if a future release skipped backward compatibility? "Marc G. Fournier" <scrappy@hub.org> 19 октября 2009 г. в 22:56:01

Re: Could postgres be much cleaner if a future release skipped backward compatibility? Tom Lane <tgl@sss.pgh.pa.us> 19 октября 2009 г. в 23:02:20

Re: Could postgres be much cleaner if a future release skipped backward compatibility? "Greg Sabino Mullane" <greg@turnstep.com> 20 октября 2009 г. в 11:07:45

Re: Could postgres be much cleaner if a future release skipped backward compatibility? Tom Lane <tgl@sss.pgh.pa.us> 20 октября 2009 г. в 12:04:57

Re: Could postgres be much cleaner if a future release skipped backward compatibility? Robert Haas <robertmhaas@gmail.com> 20 октября 2009 г. в 11:15:15

Re: Could postgres be much cleaner if a future release skipped backward compatibility? Andrew Dunstan <andrew@dunslane.net> 20 октября 2009 г. в 11:46:41

Re: Could postgres be much cleaner if a future release skipped backward compatibility? David Fetter <david@fetter.org> 20 октября 2009 г. в 12:49:10

Re: Could postgres be much cleaner if a future release skipped backward compatibility? Tom Lane <tgl@sss.pgh.pa.us> 20 октября 2009 г. в 13:27:34

Re: Could postgres be much cleaner if a future release skipped backward compatibility? Robert Haas <robertmhaas@gmail.com> 20 октября 2009 г. в 13:12:39

Re: Could postgres be much cleaner if a future release skipped backward compatibility? Dimitri Fontaine <dfontaine@hi-media.com> 20 октября 2009 г. в 11:27:32

Re: Controlling changes in plpgsql variable resolution Robert Haas <robertmhaas@gmail.com> 19 октября 2009 г. в 14:57:05

Re: Controlling changes in plpgsql variable resolution Tom Lane <tgl@sss.pgh.pa.us> 19 октября 2009 г. в 15:09:20

Re: Controlling changes in plpgsql variable resolution Merlin Moncure <mmoncure@gmail.com> 19 октября 2009 г. в 14:45:39

Re: Controlling changes in plpgsql variable resolution Tom Lane <tgl@sss.pgh.pa.us> 19 октября 2009 г. в 15:14:36

Re: Controlling changes in plpgsql variable resolution Robert Haas <robertmhaas@gmail.com> 18 октября 2009 г. в 16:53:32

Re: Controlling changes in plpgsql variable resolution Tom Lane <tgl@sss.pgh.pa.us> 18 октября 2009 г. в 17:08:03

Re: Controlling changes in plpgsql variable resolution Robert Haas <robertmhaas@gmail.com> 18 октября 2009 г. в 18:57:25

On Oct 19, 2009, at 11:47 AM, Tom Lane wrote:

> 1. Invent a GUC that has the settings backwards-compatible,
> oracle-compatible, throw-error (exact spellings TBD).  Factory  
> default,
> at least for a few releases, will be throw-error.  Make it SUSET so  
> that
> unprivileged users can't break things by twiddling it; but it's still
> possible for the DBA to set it per-database or per-user.
>
> 2. Also invent a #option syntax that allows the GUC to be overridden
> per-function.  (Since the main GUC is SUSET, we can't just use a
> per-function SET to override it.  There are other ways we could do  
> this
> but none seem less ugly than #option...)

What about adopting the modifier syntax you're adding to COPY?

David

В списке pgsql-hackers по дате отправления

Предыдущее

От: Tom Lane

Дата: 19 октября 2009 г. в 15:50:20

Сообщение: Re: Controlling changes in plpgsql variable resolution

Следующее

От: Tom Lane

Дата: 19 октября 2009 г. в 16:06:19

Сообщение: Re: Controlling changes in plpgsql variable resolution